UNIVERSITATEA TEHNIC A MOLDOVEI

Emilian GUULEAC

Ingineria programrii
ndrumar de laborator

Chiinu 2011

UNIVERSITATEA TEHNIC A MOLDOVEI

Catedra Calculatoare

Ingineria programrii
ndrumar de laborator

Chiinu U.T.M. 2011

1

Lucrarea prezint ndrumarul de laborator la disciplina " Ingineria Programrii ", destinat studenilor anului III ciclului I de licen cu specializarea 526.1 "Calculatoare", Facultatea Calculatoare, Informatic i Microelectronic. Tematica lucrrilor de laborator a fost stabilit n conformitate cu programa de nvmnt. Sunt prezentate unele consideraii teoretice privind principale tipuri de diagrame UML i exemple de aplicare. Sunt analizate i soluionate tipuri de probleme cu aplicaii Enterprise Architect.

Elaborare: conf. univ., dr. hab. Emilian GUULEAC Recenzent: conf. univ., dr. Sergiu ZAPOROJAN

Aprobat la edina Consiliului tiinific al Facultii Calculatoare, Informatic i Microelectronic din 05 mai 2011 Redactor responsabil: conf. univ., dr. Victor ABABII

Procesare computerizat: conf. univ., dr. hab. Emilian GUULEAC

U.T.M., 2010

Cuprins
Introducere
4

1. Fazele ingineriei programrii............................................................................................ 6 2. Metodologii de dezvoltare............................................................................................... 9 3. UML- Limbaj de modelare unificat........................................ 27 4. Tipuri de organizare a diagramelor UML................................................................ 14 5. Lucrare de laborator nr. 1. Elaborarea documentului de specificare a cerintelor.................................................................................................................................... 37 6. Lucrare de laborator nr. 2. Diagrama cazurilor de utilizare............................. 40 7. Lucrare de laborator nr. 3 Diagrama de clase..... 50 8. Lucrare de laborator nr. 4 Diagrama de interaciuni .. 60 9. Lucrare de laborator nr. 5 Diagrama de activiti i diagrama de stare a obiectelor......................................................................................... 69 10. Lucrare de laborator nr. 6 Diagrama de componente......................................... 82 11. Lucrare de laborator nr. 7 Diagrama de desfurare.......................................... 89 Bibliografie Anexe A.1. Teme pentru laborator..............................................................................................
95 96 96

A.2. Ghid de utilizare a instrumentului Enterprise Architect ................. 97

Introducere
n aceast lucrare vom aborda subiecte legate de procesul de dezvoltare i ntretinere a unui produs software. Multe dintre tehnicile care se aplica n acest domeniu sunt similare celor utilizate de inginerii care lucreaza n industrie, de exemplu de catre constructorii de automobile, poduri sau televizoare. De altfel, domeniul poarta numele de inginerie software. Ne vom referi la sisteme software de dimensiuni mari. Problemele care apar la dezvoltarea unor astfel de sisteme nu sunt asemntoare celor cu care ne confruntam la scrierea unei aplicatii simple. n acest caz apar probleme noi, cum ar fi cele legate de faptul ca dezvoltarea unui sistem complex presupune implicarea pe termen lung a unui mare numar de persoane, iar pe parcursul procesului specificaiile se pot modifica sau personalul se poate schimba (prin transfer, promovare etc.). Prin urmare, ingineria software se ocupa i de probleme legate de personal sau de managementul proiectelor, care sunt mai apropiate de domeniul tiintelor economice dect de informatica. Problema fundamental a ingineriei programrii este ndeplinirea cerinelor clientului. Aceasta trebuie realizat ntr-un mod flexibil i pe termen lung. Ingineria programrii se ocup cu toate etapele dezvoltrii programelor, de la extragerea cerinelor de la client pn la ntreinerea i retragerea din folosin a produsului livrat. Pe lng cerinele funcionale, clientul dorete (de obicei) ca produsul final s fie realizat cu costuri de producie ct mai mici. De asemenea, este de dorit ca aceasta s aib performane ct mai bune (uneori direct evaluabile), un cost de ntreinere ct mai mic, s fie livrat la timp, i s fie sigur. Aceste etape au fost ignorate n trecut, ns n prezent orice dezvoltator recunoate importanta acestor faze, deoarece s-a dovedit c de acestea depinde producerea i refolosirea de software. Aceste faze trebuie sa fie gata nainte de realizarea codului.
4

Pentru analiza i proiectarea programelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling Language). UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT Object Modeling Technique, and OOSE Object Oriented Software Engineering). UML se constituie din unirea acestor limbaje de modelare i n plus deine o expresivitate care ajuta la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. Este un limbaj de modelare care ofera o exprimare grafica a structurii i comportamentului software [2]. Ingineria sistemelor software include: metodologii de dezvoltare (analiza si proiectare) software (OMT, OOSE, XP, AP, etc.); instrumentele software de analiz, proiectare, modelare, testare, validare, generare teste, generare cod, etc. (CASE tools) notatii i limbaje vizuale (UML)

1. Fazele ingineriei programrii

Exist patru faze fundamentale ale metodologiilor ingineriei programrii: analiza (ce dorim s construim); proiectarea (cum vom construi); implementarea (construirea propriu-zis); testarea (asigurarea calitii). Faza de analiz.Aceast faz definete cerinele sistemului, independent de modul n care acestea vor fi ndeplinite. Aici se definete problema pe care clientul dorete s o rezolve. Rezultatul acestei faze este documentul cerinelor, care trebuie s precizeze clar ce trebuie construit. Faza de analiz poate fi vzut ca o rafinare a detaliilor. Distincia dintre detaliile de nivel nalt i cele de nivel sczut sunt puse mai bine n eviden de abordrile top-down (unde se merge ctre detaliile de nivel sczut) i bottom-up (care tind ctre detaliile de nivel nalt). Documentul cerinelor poate fi realizat ntr-o manier formal, bazat pe logic matematic, sau poate fi exprimat n limbaj natural. n mod tradiional, el descrie obiectele din sistem i aciunile care pot fi realizate cu ajutorul obiectelor. Mai concret, documentul trebuie s conin descrieri pentru urmtoarele categorii: Obiecte: Documentul trebuie s defineasc mai nti vocabularul sistemului, care este bazat n mare parte pe construcii substantivale pentru identificarea pieselor, prilor componente, constantelor, numelor i a relaiilor dintre acestea; Aciuni: Documentul trebuie s defineasc de asemenea aciunile pe care trebuie s le ndeplineasc sistemul i care sunt sugerate n general de construcii verbale. Exemple de aciuni sunt: metodele, funciile sau procedurile;
6

 Stri: Fiecare sistem trece printr-o serie de schimbri de stare. Exemple de stri sunt: starea iniial, cea final sau strile de eroare. Cele mai multe stri depind de domeniul problemei. Strile sunt asociate cu obiectele sistemului. Un eveniment declaneaz o tranziie de stare care poate conduce la ndeplinirea unei aciuni de ctre sistem; Scenarii tipice: Un scenariu este o secven de pai urmai pentru ndeplinirea unui scop. Cnd sistemul este terminat i aplicaia este disponibil, clientul trebuie s poat utiliza, ntr-o manier ct mai facil i clar specificat, toate scenariile tipice ale aplicaiei. Scenariile tipice trebuie s reprezinte majoritatea scenariilor de utilizare ale aplicaiei. Ponderea acestora variaz de la un sistem la altul, dar 90% se consider o proporie acceptabil. Scenarii atipice: Un scenariu atipic trebuie s fie ndeplinit de sistem numai n cazuri speciale. Clientul poate s spere, de exemplu, c o eroare neprevzut este un eveniment atipic. Totui, sistemul trebuie s gestioneze un numr ct mai mare de categorii de erori, prin tehnici stabilite, precum tratarea excepiilor, monitorizarea proceselor etc.; Cerine incomplete sau nemonotone: O enumerare complet a cerinelor pentru toate situaiile care pot aprea n condiii de lucru reale nu este posibil. Procesul de stabilire a cerinelor are o natur iterativ i nemonoton. Mulimea iniial de cerine definete posibilitile sistemului. Noile cerine pot infirma soluiile vechi. Pe msur ce un sistem crete n dimensiuni i complexitate, stabilirea cerinelor devine din ce n ce mai dificil, mai ales cnd procesul de colectare a cerinelor este distribuit, fiind realizat de indivizi cu specializri diferite.

Faza de proiectare. n baza cerinelor din faza de analiz, se va stabili arhitectura sistemului: componentele sistemului, interfeele i modul lor de comportare: Componentele sunt elementele constructive ale produsului. Acestea pot fi create de la zero sau reutilizate dintr-o bibliotec de componente. Componentele rafineaz i captureaz semnificaia detaliilor din documentul cerinelor; Interfeele ajut la mbinarea componentelor. O interfa reprezint grania dintre dou componente, utilizat pentru comunicarea dintre acestea. Prin intermediul interfeei, componentele pot interaciona; Comportamentul, determinat de interfa, reprezint rspunsul unei componente la stimulii aciunilor altor componente. Documentul de proiectare descrie planul de implementare a cerinelor. Se identific detaliile privind limbajele de programare, mediile de dezvoltare, dimensiunea memoriei, platforma, algoritmii, structurile de date, definiiile de tip globale, interfeele etc. n aceast faz trebuie indicate i prioritile critice pentru implementare. Acestea sugereaz sarcinile care, dac nu sunt executate corect, conduc la eecul sistemului. Totui, chiar dac prioritile critice sunt ndeplinite, acest fapt nu duce automat la succesul sistemului, ns crete nivelul de ncredere c produsul. Analiza performanelor presupune studierea modului n care diferitele arhitecturi conduc la diferite caracteristici de performan pentru fiecare scenariu tipic. n funcie de frecvena de utilizare a scenariilor, fiecare arhitectur va avea avantaje i dezavantaje. Un rspuns rapid la o aciune a utilizatorului se realizeaz deseori pe baza unor costuri de resurse suplimentare: indeci, managementul cacheului, calcule predictive etc.

Planul de implementare i planul de test, descrise mai jos, pot fi incluse de asemea n fazele de implementare i respectiv testare. ns unul din scopurile fazei de proiectare este stabilirea unui plan pentru terminarea sistemului, de aceea cele dou planuri au fost incluse n paragraful curent. Planul de implementare stabilete programul dup care se va realiza implementarea i resursele necesare (mediul de dezvoltare, editoarele, compilatoarele etc.). Planul de test definete testele necesare pentru stabilirea calitii sistemului. Dac produsul trece toate testele din planul de test, este declarat terminat. Acoperirea testului este procentajul din produs verificat prin testare. n mod ideal, o acoperire de 100% ar fi excelent, ns este rareori ndeplinit. De obicei, un test cu o acoperire de 90% este simpl, ns ultimele 10% necesit o perioad de timp semnificativ. Faza de implementare. n aceast faz, sistemul este construit, ori plecnd de la zero, ori prin asamblarea unor componente pre-existente. Pe baza documentelor din fazele anterioare, echipa de dezvoltare ar trebui s tie exact ce trebuie s construiasc, chiar dac rmne loc pentru inovaii i flexibilitate. Echipa trebuie s gestioneze problemele legate de calitate, performan, biblioteci i debug. Scopul este producerea sistemului propriu-zis. O problem important este ndeprtarea erorilor critice. ntr-un sistem exist trei tipuri de erori: Erori critice: mpiedic sistemul s satisfac n mod complet scenariile de utilizare. Aceste erori trebuie corectate nainte ca sistemul s fie predat clientului i chiar nainte ca procesul de dezvoltare ulterioar a produsului s poat continua; Erori necritice: Sunt cunoscute, dar prezena lor nu afecteaz n mod semnificativ calitatea observat a sistemului. De obicei aceste erori sunt listate n notele de lansare i au modaliti de ocolire bine cunoscute; Erori necunoscute: Exist ntotdeauna o probabilitate mare ca sistemul s
9

conin un numr de erori nedescoperite nc. Efectele acestor erori sunt necunoscute. Unele se pot dovedi critice, altele pot fi rezolvate cu patch-uri sau eliminate n versiuni ulterioare. Faza de testare. n multe metodologii ale ingineriei programrii, faza de testare este o faz separat, realizat de o echip diferit dup ce implementarea s-a terminat. Motivul este faptul c un programator nu-i poate descoperi foarte uor propriile greeli. O persoan nou care privete codul poate descoperi greeli evidente care scap celui care citete i recitete materialul de multe ori. Din pcate, aceast practic poate determina o atitudine indiferent fa de calitate n echipa de implementare. Testele de regresiune (engl. regression test) sunt colecii de programe care testeaz una sau mai multe trsturi ale sistemului. Rezultatele testelor sunt adunate i dac exist erori, bug-ul este corectat. Un test de regresiune valid genereaz rezultate verificate, numite standardul de aur. Validitatea rezultatului unui test ar trebui s fie determinat de documentul cerinelor. Testele sunt colectate, mpreun cu rezultatele standardelor de aur, ntr-un pachet de test de regresiune. Pe msur ce dezvoltarea continu, sunt adugate mai multe teste noi, iar testele vechi pot rmne valide sau nu. Dac un test vechi nu mai este valid, rezultatele sale sunt modificate n standardul de aur, pentru a se potrivi ateptrilor curente. Exist patru puncte de interes n testele de regresiune pentru asigurarea calitii. Testarea intern trateaz implementarea de nivel sczut. Fiecare funcie sau component este testat de ctre echipa de implementare. Aceste teste se mai numesc teste clear-box sau white-box, deoarece toate detaliile sunt vizibile pentru test. Testarea unitilor testeaz o unitate ca un ntreg. Aici se testeaz interaciunea mai multor funcii, dar numai n cadrul unei singure uniti. Testarea este determinat

10

de arhitectur. Aceste teste se mai numesc teste black-box deoarece numai detaliile interfeei sunt vizibile pentru test. Testarea aplicaiei testeaz aplicaia ca ntreg i este determinat de scenariile echipei de analiz. Aplicaia trebuie s execute cu succes toate scenariile pentru a putea fi pus la dispoziia clientului. Spre deosebire de testarea intern i a unitilor, care se face prin program, testarea aplicaiei se face de obicei cu scripturi care ruleaz sistemul cu o serie de parametri i colecteaz rezultatele. n trecut, aceste scripturi erau create manual. n prezent, exist instrumente care automatizeaz i acest proces. Majoritatea aplicaiilor din zilele noastre au interfee grafice (GUI). Testarea interfeei grafice pentru asigurarea calitii poate pune anumite probleme. Cele mai multe interfee, dac nu chiar toate, au bucle de evenimente, care conin cozi de mesaje de la mouse, tastatur, ferestre etc. Asociate cu fiecare eveniment sunt coordonatele ecran. Testarea interfeei presupune deci memorarea tuturor acestor informaii i elaborarea unei modaliti prin care mesajele s fie trimise din nou aplicaiei, la un moment ulterior. Testarea la stres determin calitatea aplicaiei n mediul su de execuie. Aceasta este cea mai dificil i complex categorie de teste. Sistemul este supus unor cerine din ce n ce mai numeroase, pn cnd acesta cade. Apoi produsul este reparat i testul de stres se repet pn cnd se atinge un nivel de stres mai ridicat dect nivelul ateptat de pe staia clientului.

11

2. Metodologii de dezvoltare
Fr o metodologie adecvat, dezvoltarea produsului este haotic. Unele companii folosesc propriile metodologii, altele folosesc metodologii comerciale. Alegerea unei metodologii de dezvoltare trebuie s in seama de natura fiecrui proiect: Bugetul Mrimea echipei Tehnologia utilizat Instrumentele i metodele Termenele limit Procesele existente deja 2.1 Abordarea codeaz i repar Din engl. code and fix, este cel mai des ntlnit metodologie, de fapt este cea mai rapid i mai puin eficient metod de dezvoltare a aplicaiilor. Aici nu exist reguli stabilite, deseori se ntlnete n companii mici, la nceput, cu puini programatori. 2.2 Metodologia secvenial n metodologia secvenial, cunoscut i sub numele de metodologia cascad, are loc mai nti faza de analiz, apoi cea de proiectare, urmat de cea de implementare, iar n final se realizeaz testarea. Echipele care se ocup de fiecare faz pot fi diferite, iar la fiecare tranziie de faz poate fi necesar o decizie managerial.

Figura 2.1. Metodologia secvenial

12

2.3 Metodologia cascad Procesul curge de la etap la etap, ca apa ntr-o cascad, engl. waterfall. Modelul cascad cu feedback propune remedierea problemelor descoperite n pasul precedent. Avantaje: Metodologia secvenial este potrivit cnd complexitatea sistemului este mic iar cerinele sunt statice. Foreaz meninerea unei discipline de lucru care evit presiunea scrierii codului nainte de a cunoate precis ce produs va trebui de fapt construit. Dezavantaje Unul din principalele dezavantaje ale metodologiei secveniale este faptul c acord o foarte mare importan fazei de analiz. Comunicarea dintre echipe este o problem: cele patru echipe pot fi diferite iar comunicarea dintre ele este limitat. Modul principal de comunicare sunt documentele realizate de o echip i trimise urmtoarei echipe cu foarte puin feedback. procesului de dezvoltare nghearea prematur a cerinelor conduce la obinerea unui produs prost structurat i care nu execut ceea ce dorete utilizatorul 2.4 Metodologia ciclic Metodologia ciclic, cunoscut i sub numele de metodologia spiral, ncearc s rezolve unele din problemele metodologiei secveniale. Aceast
13 Figura 2.2. Metodologia cascad

Clientul obine o viziune practic asupra produsului doar n momentul terminrii

metodologie are patru faze, ns n fiecare faz se consum un timp mai scurt, dup care urmeaz mai multe iteraii prin toate fazele. Documentele de la fiecare faz i schimb treptat structura i coninutul, la fiecare ciclu sau iteraie. Pe msur ce procesul nainteaz, sunt generate din ce n ce mai multe detalii. n final, dup cteva cicluri, sistemul este complet i gata de lansare. Procesul poate ns continua pentru lansarea mai multor versiuni ale produsului.

Figura 2.3 Metodologia ciclic

2.5 Metodologia spiral Ciclul 1 Analiza preliminar 1. Obiective, alternative, constrngeri 2. Analiza riscului i prototipul 3. Conceperea operaiilor 4. Cerinele i planul ciclului de via 5. Obiective, alternative, constrngeri 6. Analiza riscului i prototipul Ciclul 2 Analiza final 7. Simulare, modele, benchmark-uri 8. Cerine software i validare 9. Plan de dezvoltare 10. Obiective, alternative, constrngeri 11. Analiza riscului i prototipul Ciclul 3 Proiectarea 12. Simulare, modele, benchmark-uri
14 Figura 2.4. Metodologia spiral

13. Proiectarea produsului software, validare i verificare 14. Integrare i plan de test 15. Obiective, alternative, constrngeri 16. Analiza riscului i prototipul operaional Ciclul 4 Implementarea i testarea 17. Simulare, modele, benchmark-uri 18. Proiectare detaliat 19. Cod 20. Integrarea unitilor i testarea acceptrii 21. Lansarea produsului Avantaje: Metodologia ciclic se bazeaz pe ideea perfecionrii incrementale ale metodologiei secveniale. Permite feedback-ul de la fiecare echip n ceea ce privete complexitatea cerinelor. Exist etape n care pot fi corectate eventualele greeli privind cerinele. Clientul poate arunca o privire asupra rezultatului i poate oferi informaii importante mai ales n faza dinaintea lansrii produsului. Echipa de implementare poate trimite echipei de analiz informaii privind performanele i viabilitatea sistemului. Dezavantaje: Metodologia ciclic nu are nici o modalitate de supraveghere care s controleze oscilaiile de la un ciclu la altul. n aceast situaie, fiecare ciclu produce un efort mai mare de munc pentru ciclul urmtor, ceea ce ncarc orarul planificat i poate duce la eliminarea unor funcii sau la o calitate sczut. Lungimea sau numrul de cicluri poate crete foarte mult. De vreme ce nu exist constrngeri asupra echipei de analiz s fac lucrurile cum trebuie de prima dat, acest fapt duce la scderea responsabilitii. Echipa de implementare poate primi sarcini la care ulterior se va
15

renuna. Echipa de proiectare nu are o viziune global asupra produsului i deci nu poate realiza o arhitectur complet. Nu exist termene limit precise. Ciclurile continu fr o condiie clar de terminare. Echipa de implementare poate fi pus n situaia nedorit n care arhitectura i cerinele sistemului sunt n permanen schimbare. 2.6 Metodologia hibrid ecluz Metodologia ecluz (engl. watersluice), propus de Ronald LeRoi Burback (1998), separ aspectele cele mai importante ale procesului de dezvoltare a unui produs software de detaliile mai puin semnificative i se concentreaz pe rezolvarea primelor. Pe msur ce procesul continu, detaliile din ce n ce mai fine sunt rafinate, pn cnd produsul poate fi lansat. Aceast metodologie hibrid preia natura iterativ a metodologiei spiral, la care adaug progresul sigur al metodologiei cascad.

Figura 2.5 Metodologia hibrid ecluz

Etapele principale ale metodei sunt: schia de principiu, prototipul, versiunile alfa/beta i produsul final. n prima etap, schia de principiu, echipele lucreaz simultan la toate fazele problemei. Echipa de analiz sugereaz cerinele. Echipa de proiectare le discut i trimite sarcinile critice de implementare echipei de implementare. Echipa de testare
16

pregtete i dezvolt mediul de test n funcie de cerine. Echipa de implementare se concentreaz asupra sarcinilor critice, care n general sunt cele mai dificileOdat ce componentele critice au fost realizate, sistemul este gata de a face tranziia ctre stadiul de prototip. n cea de a doua etap, de prototip, cerinele i documentul cerinelor sunt ngheate. Schimbrile n cerine sunt nc permise, ns ar trebuie s fie foarte rare i numai dac sunt absolut necesare, deoarece modificrile cerinelor n acest stadiu al proiectului sunt foarte costisitoare. Este posibil totui ajustarea arhitecturii, pe baza noilor opiuni datorate tehnologiei. Dup ce sarcinile critice au fost terminate, echipa de implementare se poate concentra pe extinderea acestora, pentru definirea ct mai multor aspecte ale aplicaiei. Acum produsul este gata pentru lansarea versiunilor alfa i beta. Arhitectura este ngheat, iar accentul cade pe implementare i asigurarea calitii. Prima versiune lansat se numete n general alfa. Produsul este nc imatur; numai sarcinile critice au fost implementate la calitate ridicat. O a doua lansare reprezint versiunea beta. Rolul su este de a convinge clienii c aplicaia va fi un produs adevrat. Cnd o parte suficient de mare din sistem a fost construit, poate fi lansat n sfrit produsul. n aceast etap, implementarea este ngheat i accentul cade pe asigurarea calitii. Scopul este realizarea unui produs competitiv. n produsul final nu se accept erori critice. Avantaje: Metodologia ecluz recunoate faptul c oamenii fac greeli i c nici o decizie nu trebuie s fie absolut. Echipele nu sunt blocate ntr-o serie de cerine sau ntr-o arhitectur imobil care se pot dovedi mai trziu inadecvate sau chiar greite. Totui, pentru respectarea termenelor limit, metodologia impune date de ngheare a unor faze. Exist timp suficient pentru corectarea greelilor decizionale pentru atingerea unui nivel suficient de ridicat de ncredere. Se pune mare accent pe comunicarea ntre

17

echipe, ceea ce reduce cantitatea de cod inutil la care ar trebui s se renune n mod normal. Dezavantaje: Metodologia presupune asumarea unor responsabiliti privind delimitarea etapelor i nghearea succesiv a fazelor de dezvoltare. Ea presupune crearea unui mediu de lucru n care acceptarea responsabilitii pentru o decizie care se dovedete mai trziu greit s nu se repercuteze n mod negativ asupra individului. Se dorete de asemenea schimbarea atitudinii echipelor fa de testare, care are loc nc de la nceput, i fa de comunicarea continu, care poate fi dificil, ntruct cele patru faze reprezint perspective diferite asupra realizrii produsului. 2.7 Prototipizarea Prototipul ajut clientul n a-i defini mai bine cerinele i prioritile. Prototipul este de obicei produs ct mai repede, deci stilul de programare este de obicei neglijent. Se disting dou feluri de prototipuri: Abandonabil (throw-away) doar obinerea unei specificaii Evoluionar crearea unui schelet al aplicaiei Avantaje: Permite dezvoltatorilor s elimine lipsa de claritate a specificaiilor. Ofer utilizatorilor ansa de a schimba specificaiile ntr-un mod ce nu afecteaz drastic durata de dezvoltare. ntreinerea este redus, deoarece validarea se face pe parcursul dezvoltrii. Se poate facilita instruirea utilizatorilor finali nainte de terminarea produsului. Dezavantaje: Deoarece prototipul ruleaz ntr-un mediu artificial, anumite dezavantaje ale produsului final pot fi scpate din vedere de clieni. Clientul nu nelege de ce produsul necesit timp suplimentar pentru dezvoltare, avnd n vedere c prototipul a fost realizat att de repede. Deoarece au n fiecare moment ansa de a face acest lucru,
18

clienii schimb foarte des specificaiile. Poate fi nepopular printre dezvoltatori, deoarece implic renunarea la propria munc. 2.8 Modelul V Dezvoltat pentru reglementarea dezvoltrii de software n administraia federal german germ. V-Modell. Evideniaz testarea pe tot parcursul ciclului de dezvoltare. Trecerea la faza urmtoare se face numai dup ce toate produsele din faza curent au trecut testele de verificare i validare. Procesul de verificare i validare are scopul detectrii ct mai multor erori n ciclul de dezvoltare

Figura 2.6. Modelul - V

2.9 Metod de programare agil Metod de programare agil, potrivit dezvoltrii rapide de aplicaii Principiile metodelor agile: Implicarea clientului Clientul trebuie implicat pe tot parcursul procesului de dezvoltare. Rolul su este de a prioritiza noile cerine i de a evalua iteraiile sistemului Livrarea incremental Programul este dezvoltat incremental, clientul indicnd cerinele care trebuie incluse la fiecare iteraie
19

Oamenii nu procesul Abilitile echipei de dezvoltare trebuie recunoscute i exploatate. Echipa trebuie lsat s-i contureze propriile modaliti de lucru, fr a i se da reete Acceptarea schimbrii Echipa trebuie s se atepte ca cerinele s se schimbe iar proiectarea sistemului trebuie fcut astfel nct s se adapteze uor la aceste schimbri Meninerea simplitii Concentrare pe simplitate att n programele dezvoltate ct i n procesul de dezvoltare. Oricnd este posibil, trebuie eliminat complexitatea din sistem Problemele metodelor agile. Este dificil meninerea interesului clienilor implicai n proces. Membrii echipei pot fi incapabili s se adapteze la implicarea intens caracteristic metodelor agile. Cnd exist mai muli factori de decizie, este dificil prioritizarea schimbrilor. Meninerea simplitii necesit lucru suplimentar. Contractele pot fi o problem n cazul dezvoltrii iterative. 2.9 Extreme Programming XP consider c dezvoltarea programelor nu nseamn ierarhii, responsabiliti i termene limit, colaborarea oamenilor din care este format echipa. Acetia sunt ncurajai s i afirme personalitatea, s ofere i s primeasc cunotine. XP consider c dezvoltarea de programe nseamn n primul rnd scrierea de programe, nu documente, edine i rapoarte Carta drepturilor dezvoltatorului: Ai dreptul s tii ceea ce se cere, prin cerine clare, cu declaraii clare de prioritate Ai dreptul s spui ct i va lua s implementezi fiecare cerin, i s i revizuieti estimrile n funcie de experien Ai dreptul s i accepi responsabilitile, n loc ca acestea s-i fie atribuite Ai dreptul s faci treab de calitate n orice moment
20

 Ai dreptul la linite, distracie i la munc productiv i plcut Carta drepturilor clientului: Ai dreptul la un plan general, s tii ce poate fi fcut, cnd, i la ce pre Ai dreptul s vezi progresul ntr-un sistem care ruleaz i care se dovedete c funcioneaz trecnd teste repetabile pe care le specifici tu Ai dreptul s te rzgndeti, s nlocuieti funcionaliti i s schimbi prioritile Ai dreptul s fii informat de schimbrile n estimri, suficient de devreme pentru a putea reduce cerinele astfel ca munca s se termine la data prestabilit. Poi chiar s te opreti la un moment dat i s rmi cu un sistem folositor care s reflecte investiia pn la acea dat Caracteristici: 1. Echipa de dezvoltare nu are o structur ierarhic; fiecare contribuie la proiect folosind maximul din cunotinele sale 2. Proiectul este n mintea tuturor programatorilor din echip, nu n documentaii, modele sau rapoarte 3. Cerinele clientului sunt exprimate ca scenarii sau povestiri (user stories) 4. Acestea sunt scrise pe bileele iar echipa de dezvoltare le mparte n sarcini de implementare (care stau la baza planificrii orarului de lucru i a estimrii costurilor) 5. La orice moment, un reprezentant al clientului este disponibil pentru clarificarea cerinelor 6. Scrierea de cod este activitatea cea mai important 7. La fiecare pas se face numai ce este absolut necesar n momentul urmtor 8. Codul se scrie ct mai simplu i se optimizeaz (refactoring) de cte ori e posibil 9. Se scrie mai nti cod de test
21

10. fr mil 11. 12. 13.

Dac apare necesitatea rescrierii sau eliminrii codului, aceasta se face Modificrile aduse codului sunt integrate continuu (de cteva ori pe zi) Se programeaz n echip (programare n perechi); echipele se schimb la Se lucreaz 40 de ore pe sptmn, fr lucru suplimentar 2.10 Metodologia Open Source Open source = surs la vedere. O abordare recent, aprut ca urmare a

sfritul unei iteraii (1-2 sptmni)

dezvoltrii mijloacelor de comunicaie: FTP, e-mail, grupuri de discuie. Exemple clasice: sistemul de operare Linux, browser-ul Netscape 5. Codul surs este transmis utilizatorului final ntr-o manier non-proprietar (fr patent), pe baza unei licene open-source (gen GNU) Critici: Nu exist documente de proiectare sau alte documentaii ale proiectului. Nu se realizeaz testarea la nivel de sistem. Nu exist cerine ale utilizatorilor n afar de funcionalitatea de baz. Marketingul produsului este incomplet O iteraie tipic: Dezvoltatorul realizeaz proiectarea i codarea (individual sau n echip). Ceilali dezvoltatori sau comunitatea de utilizatori realizeaz debugging-ul i testare. Noile funcionaliti dorite i erorile depistate sunt trimise iniiatorului proiectului. Se lanseaz o nou versiune cu erorile corectate i se analizeaz noile cerinele. Se distribuie o list de sarcini ctre comunitatea de utilizatori, cutndu-se membri voluntari care s execute sarcinile de pe list 2.11 Rational Unified Process Rational Unified Process (RUP) este un proces iterativ de dezvoltare software creat de Rational Software i dezvoltat de IBM dup preluarea acestei companii n 2002. Varianta generic i deschis a RUP se numete Unified Process (UP).
22

Rdcinile RUP sunt ancorate n modelul spiral. RUP a fost rezultatul unui studiu amplu care a cutat s determine cauzele comune ale eecului proiectelor software, reprezentnd n fapt o concentrare a celor mai bune practici de dezvoltare a sistemelor. RUP se bazeaz pe un set de principii: dezvoltarea iterativ, managementul cerinelor (identificarea i specificarea corect a tuturor nevoilor utilizatorilor dar i permanenta urmrire a modificrii acestor nevoi), folosirea unei arhitecturi bazate pe componente, modelarea vizual, verificarea calitii software-ului produs, controlul modificrilor aduse ulterior Pentru determinarea corect a cerinelor RUP consider necesare desfurarea urmtoarelor activiti: analiza problemelor i situaiilor aprute n activitatea ntreprinderii, nelegerea corect a nevoilor utilizatorilor i managerilor, definirea sistemului (este necesar sublinierea importanei diagramelor usecase), actualizarea permanent a scopurilor urmrite de sistem i rafinarea definirii sistemului (se ajunge la un document detaliat care specific cerinele softwareului) Se folosete contextul general (UofD -Universe of Discourse), care este alctuit din: modelul lexical care descrie vocabularul folosit, modele ale scenariilor posibile care descriu comportamentul sistemului, un model al regulilor de afaceri care descriu regulile organizaiei. un hipertext view, o prezentare a configuraiei i un model de baz.
23

Arhitectura bazat pe componente permite dezvoltarea unui sistem care este uor de neles, ntreinut i extins. RUP promoveaz dezvoltarea arhitecturii nc din primele iteraii, arhitectur care devine un prototip care evolueaz cu fiecare iteraie pentru ca n final s se ajung la arhitectura final. Modelarea vizual se face prin diagrame UML, presupune separarea clar a modelului conceptual a software-ului de codul propriu-zis pentru a menine o viziune de ansamblu a proiectului, Ciclul de via al proiectului n RUP este mprit n patru faze principale: faza de iniializare a proiectului, faza de elaborare, faza de construcie faza de tranziie. n faza de iniializare se stabilete contextul general de dezvoltare a proiectului (completat de elemente cum ar fi diagrama use-case general, planul proiectului, analiza riscurilor i o descriere a proiectului), factorii de succes i o prognoz financiar. Pentru a considera aceast faz ncheiat trebuie satisfcute urmtoarele criterii: acordul managerilor privind scopurile urmrite i estimrile de resurse necesare; fidelitatea diagramei use-case general; credibilitatea estimrii resurselor, prioritilor i riscurilor; calitatea prototipului corelaia dintre costurile estimate i cele posibile. n faza de elaborare se realizeaz analiza domeniului i se stabilete o form iniial pentru arhitectura sistemului. Se urmrete satisfacerea urmtoarelor criterii: modelarea complet a cazurilor de utilizare i identificarea complet a actorilor implicai;
24

 o descriere corect a arhitecturii software (arhitectura sistemului presupune specificarea prilor sistemului, a modurilor de interconectare ale acestora i a regulilor de interaciune ntre prile sistemului), existena unui prototip de arhitectur care s ncorporeze cazurile de utilizare semnificative, existena unui plan de dezvoltare global pentru proiect. n faza de construcie se realizeaz n principal dezvoltarea componentelor i a trsturilor sistemului. La finalul acestei faze se obine un sistem funcional care poate fi testat. n cadrul fazei de tranziie, produsul fazei anterioare se implementeaz, sistemul fiind pregtit pentru testare i validare de ctre utilizatori. Se compar produsul cu documentaia dezvoltat n faza de iniializare. Dac se constat discrepane ntre nevoile i ateptrile utilizatorilor ntreg procesul de dezvoltare se reia. Modelul fazelor RUP

Fazele RUP: 1. Iniiere - Stabilirea cazurilor de utilizare pentru sistem. 2. Elaborare - Dezvoltarea unei nelegeri asupra domeniului problemei i asupra arhitecturii sistemului. 3. Construcie - Proiectarea, programarea i testarea sistemului. 4. Tranziie - Instalarea sistemului n mediul lui de operare. Practici recomandate de RUP: o Dezvoltarea iterativ a software-ului o Managementul cerinelor
25

o Folosirea arhitecturilor bazate pe componente o Modelarea vizual a software-ului o Verificarea calitii software-ului o Controlarea modificrilor din software 2.12 Reverse Engineering Reverse engineering = inginerie invers. Se analizeaz sistemele anterioare i se ncearc reutilizarea componenelor existente Software, hardware, documentaie, metode de lucru. Unele componente nu pot fi utilizate, altele trebuie modificate (n faza de proiectare) Componentele selectate sunt integrate direct n sistem. 2.13 Metodologia de dezvoltare Offshore Offshore = n larg. Companiile consider outsourcing-ul pentru funciile care pot fi dezvoltate mai ieftin n alt ar. Motive pentru outsourcing 1. Reducerea costurilor 2. Creterea eficienei 3. Concentrarea asupra obiectivelor critice ale proiectului 4. Accesarea flexibil a unor resurse care altfel nu ar fi accesibile (de ex. personal nalt calificat) 5. Dimensiunea mare a proiectului Etape 1. Iniierea proiectului (local) 2. Analiza cerinelor (local) 3. Proiectarea de nivel nalt (local) 4. Proiectarea detaliat (offshore) 5. Implementarea (offshore) 6. Testarea (offshore sau local) 7. Livrarea (local)
26

3. UML -Limbaj de modelare unificat

3.1 Generaliti Pentru analiza i proiectarea programelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling Language). UML nu este un simplu limbaj de modelare orientat pe obiecte, ci n prezent, este limbajul universal standard pentru dezvoltatorii software din toata lumea. UML este succesorul propriu-zis al celor mai bune trei limbaje de modelare anterioare orientate pe obiecte (mrtoda Booch creata de Grady Booch, OMT Object Modeling Techniques, i OOSE Object Oriented Software Engineering). UML se constituie din unirea acestor limbaje de modelare i n plus deine o expresivitate care ajuta la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. Limbajul este destinat vizualizrii, specificrii, construirii i documentrii sistemelor de aplicaii, dar are limitri n ceea ce privete generarea codului. UML reunete cele mai bune tehnici i practici din domeniul ingineriei programrii, care i-au dovedit eficiena n construirea sistemelor complexe. UML este un limbaj de modelare care ofera o exprimare grafica a structurii i comportamentului software. Pentru aceasta exprimare grafica se utilizeaza notatiile UML. UML este un limbaj de modelare vizual, orientat obiect, care descrie (reprezint) proprietile structurale i dinamice ale unui sistem software. Fiecare tehnic de modelare d o vedere diferit, static sau dinamic, a unei aplicaii. Notaiile UML constituie un element esential al limbajului pentru realizarea propriu-zis a modelarii i anume partea reprezentrii grafice pe care se bazeaz orice limbaj de modelare. Modelarea n acest limbaj se realizeaza prin combinarea notaiilor UML n cadrul elementelor principale ale acestora denumite diagrame. n cadrul UML-ului descoperim 9 tipuri de diagrame: diagrama cazurilor de utilizare, diagrama de secventa, diagrama de colaborare, diagrama de clase (cea mai utilizata), diagrama de stari, diagrama de componente, diagrama de obiecte, diagrama de activitati.
27

3.2 UML apariie i evoluie n octombrie 1994, Grady Booch lider stiinific la Rational Corporation, autor al metodei ce-i poart numele i aunor al cri de referint n domeniu face echip cu James Rumbaugh, autorul principal al metodei OMT, pe care-l determin s-i prseasc (cel puin temporar) vechiul loc de munc (General Electric) i s treac la firma Rational. Dup un an de activitate Booch i Rumbaugh, prezint n octombrie1995 cu ocazia conferinei OOPSLA, caracteristicile de baz ale unei noi metode de analiz i proiectare, rezultat prin unificarea Metodei lui Booch (OOD) cu OMT, metod denumit Metoda unificat (Unified Method). Prima documentaie a metodei menionate anterior a fost fcut public n decembrie 1995, avnd numrul de versiune 0.8. La sfrsitul aceluiai an celor doi li se alatur i Ivar Jacobson. n iunie 1996 apare versiunea 0.9, urmat la scurt timp, octombrie 1996, de apariia versiunii 0.91. Versiunea 0.9 aduce i schimbarea denumirii din Metoda unificat (Unified Method) n Limbajul unificat de modelare (Unified Modeling Language). Cooptarea lui Jacobson n echip se concretizeaz printre altele n detalierea conceptului de cazuri de utilizare (use case) i prezentarea unei descrieri mai amnunite pentru diagramele cazurilor de utilizare. Conceptul de stereotip este mai bine explicitat, se modific denumirile unor diagrame. La 17 noiembrie 1997, OMG a anuntat adoptarea specificaiei UML ca limbaj standard de modelare. Schimbarea denumirii din Metoda Unificat n Limbaj de Modelare Unificat UML a fost conceput ca un limbaj universal care s fie utilizat lamodelarea sistemelor (indiferent de tipul i scopul pentru care au fost construite), la fel cum limbajele de programare sunt folosite n diverse domenii.

28

3.3 Tipuri de diagrame UML Analiza unei aplicaii implic realizarea mai multor categorii de modele, dintre care cele mai importante sunt: Modelul de utilizare - realizeaz modelarea problemelor i a soluiilor acestora n maniera n care le percepe utilizatorul final al aplicaiei. Diagrama asociat: diagrama cazurilor de utilizare. Modelul structural: se realizeaz pe baza analizei statice a problemei i descrie proprietile statice ale entitilor care compun domeniul problemei. Diagrame asociate: diagrama de componente, diagram de clase. Modelul comportamental: privete descrierea funcionalitiilor i a succesiunii n timp a aciunilor realizate de entitile domeniului problemei. Diagrame asociate: diagrama de stri, diagrama de colaborare, diagrama de interaciune. Principalele pri ale UML sunt: Vederile (View) - surprind aspecte particulare ale sistemului de modelat. Un view este o abstractizare a sistemului, iar pentru construirea lui se folosete un numr de diagrame. Diagramele - sunt grafuri care descriu coninutul unui view. UML are nou tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului. Elementele de modelare - sunt conceptele folosite n diagrame care au coresponden n programarea orientat -obiect, cum ar fi: clase, obiecte, mesaje i relaii ntre acestea: asocierea, dependena, generalizarea. Un element de modelare poate fi folosit n mai multe diagrame diferite i va avea acelai nteles i acelai mod de reprezentare. Mecanismele generale - permit introducerea de comentarii i alte informaii despre un anumit element. Modelarea unui sistem poate fi o munc foarte dificil. Ideal ar fi ca pentru descrierea sistemului s se foloseasc un singur graf, ns de cele mai multe ori acesta nu poate

29

s surprind toate informaiile necesare descrierii sistemului. Un sistem poate fi descris lund n considerare diferite aspecte: Funcional: este descris structura static i comportamentul dinamic al sistemului; Non-funcional: necesarul de timp pentru dezvoltarea sistemului Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod; Aadar pentru descrierea unui sistem sunt necesare un numr de view-uri, fiecare reprezentnd aspect al sau. Fiecare vedere (view) este descris folosind un numr de diagrame care conin informaii relative la un anumit aspect particular al sistemului. Aceste parte din mai multe view-uri. Nivelul logic ne arat prile din care este compus sitemul, precum i interaciunea lor. Aceasta reprezint un set de abstractizri, accentrnd clasele i obiectele. Deci, putem spune c nivelul logic, descrie obiectul model al sistemului. Diagramele UML care ne arat nivelul logic sint diagrama claselor, i printre altele, diagrama claselor este tipul de diagram cel mai frecvent utilizat. De asemenea, diagrama de stare, diagrama obiectelor, diagrama secvenial i diagrama de colaborare. Fiecare tip de diagram are compartimentul su propriu. Nivelul proceselor acest nivel descrie, procesele ce au loc n sistem. Nivelul proceselor ne arat comunicarea dintre aceste procese i examineaz ceea ce trebuie s se ntmple n sistem. Nivelul proceselor este deosebit de util, atunci cnd sistemul va avea un numr simultan de fire de execuie sau procese, i diagrama UML ce reprezint nivelul proceselor este diagrama de activiti.
30 Figura 3.1. Vederile UML

proiecie

descrierii

intregului sistem i care reflect un anumuit

view-uri se se acoper unele pe altele, deci este posibil ca o anumit diagram s fac

Nivelul fizic acest nivel modeleaz mediul de execuie a sistemului. Nivelul fizic const n maparea artefactelor software pe hardware-ul care-l gzduiete. Diagrama de desfurare UML este utilizat pentru a modela nivelul fizic al sistemului. Nivelul de dezvoltare descrie modulele sau componentele sistemului incluznd pachete, subsisteme i biblioteci. Acest nivel ne ofer schema bloc a sistemului. Modul n care este privit, nivelul de dezvoltare este util n gestionarea straturilor sistemului. Diagrama UML care ne arat nivelul de dezvoltare include: diagrama componentelor i deasemenea diagrama pachetelor. Nivelul cazurilor de utilizare ne arat funcionalitatea sistemului, cu alte cuvinte, acest nivel ne ofer o descriere general a modului n care va fi utilizat sistemul. Nivelul cazurilor de utilizare captureaz obiectivele i scenariile utilizatorului, aceasta s-ar putea spune, c el descrie ceea ce face un sistem din punct de vedere al unui observator extern. Folosind cazurile de utilizare este util n a defini i a explica structura i funcionalitatea sistemului n celelalte patru nivele. Deci, acest nivel plus unu, ofer un ghid pentru modelele din cele patru nivele. Diagrama cazurilor de utilizare UML, mpreun cu cazurile de utilizare scrise i cerinele specificate, produce nivelul cazurilor de utilizare. Modelul patru plus unu, este important pentru c el, ne ajut s ne asigurm, c am reflectat i documentat toate aspectele importante ale sistemului nostru.
Diagramele functionale. Diagramele functionale se bazeaza exclusiv pe cazurile de utilizare (use case diagram) pentru specificarea cerintelor sistemului. Paradigma de reprezentare este ilustrata n figura 3.2 i are urmatoarea semnificatie: Actorul participa la Cazul de utilizare reprezentat n diagrama. Att actorii ct si cazurile de utilizare trebuie sa poarte denumiri unice, ntre cazurile de utilizare existnd si anumite relatii de care ne vom ocupa ulterior. Cazurile de

31

utilizare arata ce anume trebuie proiectat, far a da vreo indicaie cum s se fac acest lucru.

Diagramele statice (sau structurale) Diagramele diferitele elemente statice, de numite structura si ale

diagrame structurale, arata legaturile ntre modelului si se refera la: Diagramele de clase (class diagram), a caror paradigma de reprezentare se vede n figura 3.3, constituie punctul central al dezvoltrii obiect. n figura menionat, clasa B - caracterizat prin atributele atribut2 i atribut3 i operaiile operatie2 si operatie3 este asociat clasei A - caracterizat prin atribut1 si operatie1- printr-o relaie de agregare. Cu alte cuvinte, un numar neprecizat de instane ale clasei B (notat cu 0..*) intr n compunerea unei instane aparinnd clasei A. Pe de alta parte, clasa A este legat printr-o relaie de generalizare de sub-clasa A1 care i mosteneste proprietatile (atribut1 i operatie1) avnd n plus operatie4. -Pentru analiza, diagrama de clase este utila deoarece descrie structura entitatilor manipulate de utilizator. -n realizarea modelului, cu o diagrama de clase se reprezinta de obicei structura programelor orientate obiect sau, mai precis, modulele limbajului de dezvoltare. Diagramele de componente (component diagram), a caror paradigma de reprezentare este data n figura 3.4, constituie concepte de configurare a programelor n pachete de programe, n fisiere sursa sau n biblioteci.
Figura 3.2 diagrama cazurilor de utilizare Figura 3.3 diagrama de clase

32

Figura 3.4 diagrama de componente

Aceste concepte arata cum se leaga ntre ele fisierele sursa, pachetele de programe si bibliotecile, n cadrul sistemului informatic proiectat. Astfel, n figura mentionata sunt reprezentate pachetul de programe de tip <<Applet>>, care cuprinde toate programele de interfata om-masina (IOM) si care comunica cu pachetul de programe de tip <<Baza de date>> numit Clienti. Cele doua pachete de programe pot fi amplasate pe masini diferite sau n biblioteci diferite n cadrul sistemului informatic.

Figura 3.5 diagrama de desfurare

Diagramele de desfurare sau (deployment diagram), a caror paradigma de reprezentare se vede n figura 3.5, corespund structurii de retea informatica ce preia sistemul de programe si modului n care sunt instalate componentele de retea. Astfel, din figura 5_4 rezulta ca sistemul local este constituit din serverul central, la care sunt legate un server de nlantuire si un server Web. Diagramele dinamice (sau comportamentale) Diagramele dinamice, numite si diagrame comportamentale, arata cum interactioneaza ntre ele diferitele elemente ale modelului si sunt alcatuite din:

33

Diagramele de activitati (activities diagram), a caror paradigma de reprezentare este ilustrata n figura 3.6. Ele reprezinta regulile de nlantuire ale activitatilor n cadrul sistemului, de exemplu, navigarea ntr-un site Web. Activitatile sunt reprezentate prin dreptunghiuri ovalizate iar trecerea de la o activitate la alta prin sageti, care se ntlnesc n noduri de stare marcate prin linii verticale. Ansamblul activitatilor are un punct de intrare si un punct de iesire, marcate ca n figura.

Figura 3.6. Diagrama de activitate

Diagramele de stare (states diagram), a caror paradigma de reprezentare este data n figura 3.7. Ele reprezinta ciclul de viata comun obiectelor unei aceleiasi clase si permit completarea cunostintelor claselor, att n cadrul analizei ct si n cazul conceptiei. Conventia de reprezentare este inversa ca la diagramele de activitati, cu alte cuvinte starile sunt marcate prin dreptunghiuri cu colturi rotunjite iar drumul de la o stare la alta prin sageti reprezentnd actiuni specifice. Ca si la diagramele de activitati, exista mai multe ci prin care se poate ajunge de la o stare la alta. Alegerea unei ci sau a alteia depinde de condiiile n care se afla sistemul la momentul respectiv. n diagrama din figura 3.7 nu sunt mentionate punctele si conditiile de alegere.

Figura 3.7. Diagrama de stare

Diagramele de secventa (sequence diagram), a caror paradigma de reprezentare este ilustrata n figura 3.8. Diagramele de secventa servesc, n primul rnd, dezvoltarii
34

de scenarii n cadrul analizei utilizarii sistemului. n diagramele de secventa mesajele sunt reprezentate orizontal, pe o axa a timpului de sus n jos, de attea ori de cte ori apar.

Figura 3.8. Diagrama de secven

Diagramele de colaborare (cooperation diagram), a caror paradigma de reprezentare este data n figura 3.9.

Figura 3.9. Diagrama de colaborare

n diagramele de colaborare exista o singura cale, care uneste doua elemente (clase, actori), mesajele care circula pe aceasta cale mpreuna cu sensul lor fiind marcate pe margine cu sageti. De obicei, diagramele de colaborare se construiesc pe baza diagramelor de secventa si figureaza schimburile de mesaje ntre obiecte n cazul anumitor functionari particulare ale sistemului. Att diagramele de secventa ct si diagramele de colaborare sunt, ambele, diagrame de interactiune UML. Organizarea ierarhica a diagramelor este prezentat n Fig. 10.

35

Diagrame UML

diagrama de comportament
diagrama cazurilor de utiliare

diagrama de structur diagrama de clase

diagrama de stare diagrama de activiti diagrama de interaciune diagrama de secven diagrama de colaborare

diagrama de obiecte diagrama de pachete diagrama de componente diagrama de desfurare

Figura 3.10. Organizarea ierarhica a diagramelor

36

Lucrare de laborator nr. 1

Tema: Elaborarea documentului de specificare a cerintelor Scopul: 1. 2. 3. 4. Identificarea cerintelor funcionale i non-funcionale ale sistemului. Identificarea cerintelor utilizatorilor. Identificarea cerintelor sistemului. Elaborarea documentului de specificare a cerinelor.

Noiuni teoretice. Ingineria cerinelor este procesul de stabilire a serviciilor cerute sistemului de ctre clieni, precum i a constrngerilor sub care acesta va fi dezvoltat i va opera. Cerinele sunt descrieri ale serviciilor oferite de sistem i a constrngerilor care sunt generate de-a lungul desfurrii procesului de inginerie a cerinelor. Cerine funcionale Descrieri ale serviciilor pe care trebuie s le ofere sistemul, cum trebuie s reacioneze i s se comporte sistemul n situaii particulare. Exemplu. Fie un sistem tip bibliotec, unde utilizatorii pot cuta, aduga i tipri articole pentru studiu personal exemple de cerine funcionale pot fi: Utilizatorul trebuie s poat cuta articole n toate bazele de date sau ntrun subset selectat. Sistemul trebuie s ofere instrumente de vizualizare potrivite pentru citirea articolelor. Fiecare comand trebuie s aib alocat un identificator unic (ORDER_ID). Cerine ne-funcionale. Acestea definesc proprietile i constrngerile sistemului cum ar fi: fiabilitate, timp de rspuns i cerine de stocare. Constrngerile sunt proprieti ale componentelor de stocare de date, reprezentri ale sistemului, etc. Constrngeri asupra serviciilor sau funciilor oferite de sistem cum ar fi constrngeri de timp, constrngeri ale procesului de dezvoltare, standarde, etc. Pot fi
37

specificate cerine de proces care impun un anumit sistem CASE, un limbaj de programare sau o metod de dezvoltare. Exemplu. Fiabilitatea, timpul de rspuns, cerinele pentru spaiul de stocare, cerine ale sistemului de intrri-ieiri etc. Cerinele ne-funcionale pot fi mai critice dect cele funcionale, dac nu vor fi ndeplinite sistemul nu va fi util scopului n care a fost dezvoltat. Exemple de cerine ne-funcionale: Cerine de produs Interfaa cu utilizatorul pentru sistemul tip bibliotec trebuie s fie implementat ca pagini HTML simple fr cadre (frames) sau Java applets. Cerine externe Sistemul nu trebuie s ofere alte informaii personale legate de clieni n afar de numele lor. Cerinele sistemului reprezint un document structurat stabilind descrierea detaliat a funciilor sistemului, serviciile oferite i constrngerile operaionale. Poate fi parte a contractului cu clientul Cerine ne-funcionale ce in de: Transportul: definete constrngerile i cerinele care afecteaz transmiterea de informaii ntre noduri. Reele, relee, protocoale, calitatea serviciilor de transport chiar i transmiterea pe suporturi fizice este inclus aici. Persistena- detalizeaz criteriile operaionale i performan cu privire la stocarea de informaii, inclusiv redundan, back-up-ul, sistemul de baze de date, fiiere i alte mecanisme de stocare persistent. Securitate - cerine cu privire la acces la date att (securitate a informaiilor) i de securitate fizic (de acces la servere i alte componente hardware critice). Scalabilitate- definete parametrii de funcionare n ceea ce privete dimensiunea sistemului, numrul de tranzacii, capacitate, numrul de utilizatori i noduri distribuite.
38

 Performan - definete parametrii, cum ar fi tranzacii pe secund, viteza de transmitere n reea, form de ncrcare i alte aspecte msurabile ale sistemului care guverneaz cu viteza de ansamblu i reacia sistemului. Cerine utilizator. Cerine utilizator trebuie s descrie cerine funcionale i non-funcionale ntr-o manier n care sunt pe nelesul utilizatorilor sistemului, care nu dein cunotine tehnice detaliate. Ele sunt definite utiliznd limbajul natural, tabele i diagrame, care pot fi nelese de toi utilizatorii. Arhitectura sistemului se proiecteaz n baza cerinelor. Sistemul poate interopera cu alte sisteme care genereaz la rndul lor alte cerine Documentul de specificare a cerinelor 1. Documentul de cerine este exprimarea oficial a ceea ce se cere de la

dezvoltatorii sistemului. 2. Trebuie s includ att definiii ale cerinelor utilizator ct i specificaii

ale cerinelor de sistem. 3. NU este un document de proiectare. Pe ct este posibil, trebuie s

exprime CE trebuie s fac sistemul i nu CUM trebuie s fac Concluzii 1. 2. 3. 4. Cerinele exprim ceea ce trebuie s fac sistemul i definete constrngerile asupra operrii sau implementrii. Cerinele funcionale exprim serviciile pe care le va oferi sistemul. Cerinele ne-funcionale constrng sistemul sau procesul de dezvoltare. Cerinele utilizator sunt exprimri de nivel nalt a ceea ce trebuie s fac sistemul. Cerinele utilizator trebuie scrise n limbaj natural, eventual folosind tabele i diagrame. 5. 6. Cerinele de sistem trebuie s descrie funciile oferite de sistem. Un document de cerine software este o exprimare oficial a cerinelor sistemului.
39

7.

Standardul IEEE este un punct de start pentru definirea unor standarde mai detaliate de specificare a cerinelor. Standardul IEEE pentru cerine. Definete o structur generic pentru

documentul de cerine ce trebuie creat pentru un sistem specific. 1. Introducere. 2. Descriere general. 3. Cerine specifice. 4. Apendice. 5. Index. Lucrare de laborator nr. 2 Tema: Diagrama cazurilor de utilizare Scopul: 1. Identificarea actorilor 2. Identificarea scenariilor 3. Determinarea cazurilor de utilizare 4. Elaborarea diagramei cazurilor de utilizare Modelarea vizual n UML poate fi reprezentat ca un oarecare proces de lansare pe niveluri de la cel mai general i abstract model conceptual al sistemului iniial ctre modelul logic i mai apoi fizic, ce corespunde unui sistem de program. Pentru atingerea acestui scop de la nceput se creaz un model n form de diagarama cazurilor de utilizare (use case diagram) care descrie destinaia functional a sistemului sau cu alte cuvinte descrie ceea ce sistemul va executa n procesul su de funcionare. Diagrama cazurilor de utilizare reprezint un model iniial conceptual al unui sistem n procesul de proiectare i exploatare. Esena acestei diagrame const n faptul c: sistemul proiectat se reprezint ca o colecie de entiti i actori care colaboreaz cu sistemul cu ajutorul aa numitor
40

cazuri de utilizare. Totodat orice entitate care colaboreaz cu sistemul din afar poate fi numit actor. Aceasta poate fi un om, o instalare tehnic, un program sau oricare alt sistem care poate fi surs de aciune pentru sistemul proiectat n aa mod, cum l determin colaboratorul. La rndul su, use case-ul este creat pentru descrierea serviciilor pe care sistemul le ofer actorului. Cu alte cuvinte fiecare caz de utilizare definete o colecie de aciuni executate de sistem n timpul dialogului cu actorul. Totodat nimic nu este spus despre aceea n ce mod va fi realizat colaborare ntre actori i sistem. n caz general, diagrama cazurilor de utilizare reprezint un graf deosebit, care este o notaie grafic pentru prezentarea cazurilor de utilizare concrete, actorilor, poate i a unora interfee i pentru prezentarea legturilor ntre aceste elemente. Totodat componente aparte ale diagramei pot fi incluse ntr-un dreptunghi, care semnific sistemul proiectat n ntregime. Trebuie de specificat c legturile acestui graf pot fi de numai anumite tipuri de interaciuni ntre actori i cazuri de utilizare, care mpreun descriu servicii i cerine funcionale ctre sistemul modelat. O diagrama a cazurilor de utilizare (use case diagram) prezinta o colecie de cazuri de utilizare i actori care: ofera o descriere generala a modului n care va fi utilizat sistemul furnizeaz o privire de ansamblu a functionalitilor ce se doresc a fi oferite de sistem arat cum interacioneaz sistemul cu unul sau mai muli actori asigur faptul c sistemul va produce ceea ce s-a dorit. Caz de utilizare Structura sau elementul standart al limbajului UML caz de utilizare se folosete pentru specificarea particularitilor comune ale comportrii unui sistem sau a oricrei alte entitti n domeniul de lucru fr cercetarea structurii interne a acestei entiti. Fiecare caz de utilizare
41 Figura 1. Caz de utilizare.

determin o succesiune de aciuni care trebuie sa fie executate de ctre sistemul poiectat la colaborarea lui cu actorul corespunztor. Diagrama cazurilor de utilizare poate fi completat cu text explicativ, care desfoar sensul sau semantica componentelor ce o compun. Acest text se numete adnotare sau scenariu. Cazul de utilizare se noteaz cu o elips n interiorul creia se conine denumirea prescurtat sau numele n form de verb cu cuvinte explicative (Fig. 1). Scopul cazului de utilizare const n determinarea aspectului terminal sau fragmentului de comportare a unei entiti fr desfurarea structurii interne a acestei intiti. n calitate de aa entitate poate fi un sistem iniial sau un element al modelului care dispune de comportament propriu, precum este subsitemul sau clasa n modelul unui sistem. Fiecare caz de utilizare corespunde unui serviciu aparte, care reprezint o entitate modelat sau un sistem la cererea utilizatorului (actorului), mai precis determin metoda aplicat ctre o anumit entitate. Serviciul care este iniializat la cererea utilizatorului reprezint o succesiune terminat de aciuni. Aceasta nseamn c dup ce sistemul va termina prelucrarea cererii utilizatorului el (sistemul) trebuie sa se ntoarc n starea iniial n care este gata pentru a indeplini cererile urmtoare. Cazurile de utilizare descriu nu numai colaborarea ntre utilizatori i entiti, dar i reacia entitii la primirea anumitor mesaje de la utilizatori i asupra percepiei acestor mesaje n afar entitii. Cazurile de utilizare pot include (conine) descrierea specificaiilor modurilor de realizare a serviciului i a diferitor situaii excepionale, aa cum este prelucrarea corect a erorilor unui sistem. Mulimea cazurilor de utilizare n total poate determina toate aspecte posibile comportrii ateptate a unui sistem. Pentru comoditate mulimea cazurilor de utilizare poate fi considerat ca un pachet aparte. Din punct de vedere sistemo-analitic cazurile de utilizare pot fi folosite pentru specificarea cerinelor externe ctre sistemul proiectat i pentru specificarea comportrii funcionale a sitemului deja existent.
42

Exemple de cazuri de utilizare pot fi aciunile urmtoare: verificarea strii contului curent al clientului, intocmirea comenzii la procurarea mrfii, obinerea informaiei suplimentare despre solvabilitatea clientului, reprezentarea formei grafice la ecranul monitorului s.a. Actorul. Actorul reprezint orice entitate extern sistemului modelat, care colaboreaz cu sistemul i utilizeaz posibilitile lui funcionale pentru atingerea anumitor scopuri i pentru rezolvarea problemelor particulare. Totodat actorii sunt utilizai pentru notarea mulimii rolurilor coordonate ale utilizatorilor n procesul de colaborare cu sistemul proiectat. Fiecare actor poate fi considerat un anumit rol aparte relativ unui caz de utilizare concret. Notaia grafic standard a unui actor n diagram este omuleul sub care se indic numele actorului (Fig. 2). Identicarea actorilor se face raspunznd la urmatoarele ntrebri: Cine dorete sau este interesat de informaiile aate n sistem? Cine modic date? Cine interactioneaza cu sistemul?
Figura 2 .Actor

n unele cazuri actorul poate fi notat ca dreptunghiul clasei cu cuvntul-cheie actor i cu elementele comune ale clasei. Numele actorilor trebuie s fie scrise cu litere majuscule i trebuie s respecte recomandrile la utilizarea numelor pentru tipurile i clasele modelului. Totoadat simbolul actorului aparte leag descrierea corespunztoare a actorului cu un anumit nume. Numele actorilor abstraci, aa cum i a altor elemente abstracte n limbajul UML, se recomand de notat n italic. Ca exemplu de actori pot fi: clientul unei bnci, angajatul unei bnci, vnztorul unui magazin, managerul seciei de vnzare, pasagerul unui avion, conductorul unui auto, administratorul unui hotel, celularul i alte entiti, care au legtur cu modelul conceptual care corespunde domeniului de lucru. Actorii sunt utilizai pentru modelarea entitilor exeterne sitemului, care acioneaz reciproc cu sistemul i pe care l utilizez n calitate de utilizatori separai.
43

n calitate de actori pot fi i alte sisteme, subsisteme ale sistemului proiectat sau clase aparte. Este important s intelegem c actorul definete o anumit mulime de roluri coordonate, care pot fi utilizatorii unui sistem dat n procesul de colaborare. n fiecare moment de timp cu sistemul colaboreaz un anumit utilizator n unul din roluri date. Ca exemplu evident de actor poate fi un anumit utilizator al sistemului cu parametri de autentificare proprie. Legturile n diagrama a cazurilor de utilizare. ntre componentele diagramei cazurilor de utilizare pot s existe diferite legturi care desciu colaborarea exemplarelor unor actori i cazurilor de utilizare cu exemplarele altor actori i cazuri. Un anumit actor poate s colaboreze cu mai multe cazuri de utilizare. n acest caz actorul dat se adreseaz ctre cteva servicii ale sistemului dat. La rndul su un anumit caz de utilizare poate s colaboreze cu mai muli actori, pentru care el acord serviciul su. Trebuie de observat c dou cazuri de utilizare definite pentru aceeai entitate nu pot colabora unul cu altul, fiindc fiecare din ele descrie o variant propie terminal de utilizare a acestei entiti. Mai mult dect att, cazurile de utilizare ntotdeauna presupun careva semnale i mesaje pentru colaborarea cu actorii n afara limetelor sistemului. n acelai timp pot fi definite alte metode de colaborare ntre elemente n nteriorul sistemului. n limbajul UML sunt cteva tipuri standarde de relaii ntre actori i cazuri de utilizare: - relaia de asociere (association relationship) - relaia de extindere (extend relationship) - relaia de generalizare (generalization relationship) - relaia de cuplare (include relationship) Un actor este un stereotip al unei clase. Actorii sunt reprezentati de utilizatori sau entitati care pot interaciona cu sistemul. Ei nu fac parte din sistem i definesc multimi de roluri n comunicarea cu acesta.

44

Relaia de asociere.Relaia de asociere este o noiune fundamental n limbajul UML i mai mult sau mai puin se utilizeaz la crearea tuturor modelelor grafice n forma diagramelor canonice. Cu privire la diagrama cazurilor de utilizare relaia de asociere specific rolul deosebit al actorului n cazul de utilizare aparte. Cu alte cuvinte, asocierea specific particularitatea semantic de colaborare a actorilor i cazurilor de utilizare n modelul grafic. n aa mod aceast relaie stabilete ce rol joac actorul la colaborarea cu exemplarul cazului de utilizare. n diagrama cazurilor de utilizare precum i n alte diagrame relaia de asociere se noteaz cu o linie nentrerupt ntre actor i cazul de utilizare. Aceast linie poate s aib condiii suplementare, de exemplu, numele i multiplicitatea (Fig. 3).

Figura 3. Relaie de asociere ntre acotr i caz de utilizare.

Relaia de extindere. Relaia de extindere definete interconexiunea exemplarelor cazului de utilizare cu cazul general, proprietile cruia sunt definite pe baza modului de uniune a exemplarelor date. n metamodelul relaie de extindere este direct i indic care condiii concrete pot fi utilizate pentru unele exemple unui anumit caz de utilizare, definite pentru extinderea cazului de utilizare dat. Dac are loc relaie de extindere de la cazul de utilizare A la cazul de utilizare B, acest lucru nseamn c proprietile exemplarului cazului de utilizare B pot fi adugate datorit proprietilor extinse a cazului de utilizare A. Relaia de extindere ntre cazurile de utilizare reprezint o linie punctat cu sgeat (cazul relaiei de dependen), direct de la acel caz de utilizare, care reprezint extinderea cazului de utilizare iniial. Aceast linie cu sgeat este marcat cu cuvntul extend (extinde), Fig. 4.

45

Figura 4. Relaia de extindere ntre cazurile de utilizare.

Relaia de extindere indic acel fapt c unul din cazurile de utilizare poate fi conectat la comportamentul su care-va comportament adugtor, definit pentru un alt caz de utilizare. Relaia dat include o anumit condiie i exilri la puncte de extensie n cazul de utilizare de baz. Pentru alocarea extinderii este necesar de a executa o anumit condiie a relaiei date. Exilri la puncte de extensie definesc acele locuri n cazul de utilizare de baz n care trebuie s fie pus extinderea respectiv n timpul executrii condiiei. Unul din cazurile de utilizare pot fi extinderea pentru cteva cazuri de baz i pot avea ca extinderi proprii nc cte-va alte cazuri. Cazul de utilizare de baz poate fi adugtor independent de la alte extensii. Semantica relaiei de extensie este definit n felul urmtor. Dac exemplarul cazului de utilizare execut anumit consecven de aciuni, care definete comportamentul lui i n urma cruia exist un punct de extensie la alt exemplar a cazului de utilizare, care este unul din primele puncte de extensie a cazului iniial, atunci controleaz condiia relaiei date. Dac condiia este executat, consecvena iniial de aciuni extinde includerea aciunii altui exemplar a cazului de utilizare. Relaia de generalizare. Relaia de generalizare este folosit pentru indicarea faptului c care-va caz de utilizare A poate fi generalizat la cazul de utilizare B. n urma cruia, cazul A va fi cazul special cazului B. n urma cruia cazul B se numete printe relativ A, iar cazul A descendent relativ cazului de utilizare B. Este nevoie de menionat, c descendentul motenete toate proprietile i comportamentul printelui su i poate avea proprietile i comportamentul su adugtor. Grafic relaia dat este reprezentat cu linia ntreag cu sgeat n forma de

46

triunghi nehaurat, care indic cazul de utilizare printe (Fig. 5). Aceast linie cu sgeat are un nume specific sgeata generalizare.

Figura 5. Relaia de generalizare ntre cazuri de utilizare.

Relaia de generalizare ntre cazurile de utilizare este folosit n acele cazuri cnd este necesar de indicat c cazul de utilizare derivat conine toate atributele i particularitile comportamentului cazurilor de baz. n urma cruia cazurile de utilizare derivate pot participa n relaii cazurilor de baz. n urma sa cazurile derivate pot avea proprieti noi de comportament, care nu au cazurile de utilizare de baz, dar i de a preciza sau modifica proprietile de comportament motenite. ntre actori aparte de asemenea poate exista relaia de generalizare. Aceast relaie este direct i indic faptul c specializarea unor actori este relativ cu alii. De exemplu, relaia de generalizare de la actorul A la actorul B indic faptul c fiecare exemplar a actorului A este concomitent cu exemplarul actorului B i are toate proprietile lui. n acest caz actorul B este printe relativ cu actorul A, iar actorul A este descendentul actorului B. n urma cruia actorul A are posibilitatea de joc a aceleeai mulimi de roluri ca i actorul B, adic daca un actor motenete un alt actor, atunci el poate sa comunice cu aceleai cazuri de utilizare ale sistemului ca i parintele sau. Grafic relaia dat este reprezentat cu sgeata de generalizare, adic cu linia ntreag cu sgeat n form de triunghi nehaurat, care indic printele actorului (Fig. 6). Relaia de tip include, Relaia de tip include ntre dou cazuri de utilizare indic un comportament stabilit pentru un caz de utilizare ce este inclus ca component compus n consecutivitatea comporatamentului a altui caz de utilizare.
47
Figura 6. relaie de generalizare ntre actori.

Semantica acestei relaii este definit n felul urmtor. Cnd exemplarul primului caz de utilizare n timpul executrii ajunge la punctul de includere n consecutivitatea comporatamentului exemplarului al doilea a cazului de utilizare, exemplarul primului caz de utilizare execut consecutivitatea aciunilor, care definesc comportamentul exemplarului al doilea a cazului de utilizare, dup ce continu executarea aciunilor comportamentului su. Cazul de utilizare ce este inclus poate fi independent de cazul de baz, anume el d ultimului un comportament incapsulat, detalii realizaiei cruia sunt ascunse i pot fi liber mprite ntre cte-va cazuri de utilizare incluse. Relaia de tip include orientat de la cazul de utilizare A la cazul de utilizare B indic c fiecare exemplar al cazului A include proprieti funcionale stabilite pentru cazul B. Aceste proprieti specializeaz comportamentul cazului respectiv A n diagrama dat. Grafic relaiile date sunt indicate cu linia punctat cu sgeat (cazul relaiei de dependen), ndreptate de la cazul de utilizare de baz la cazul ce este inclus. n urma cruia linia cu sgeata este indicat cu cuvntul-cheie include, Fig. 7).

Fig. 7. Relaie de tip include ntre cazuri de utilizare.

Exemplu. Ca exemplu vom lua procesul de modelare a sistemului de vindere a mrfurilor dup catalog. n calitate de actori a sistemului dat pot fi dou subiecte, unu din care este vnztor, iar altul cumprtor. Fiecare din actori interacioneaz cu sistemul de vindere a mrfurilor dup catalog i este utilizatorul lui, adic ambele se adreseaz la servisul respectiv A perfecta comanda de cumprare a mrfii. Este evedent din cerinele adresate la sistem c servisul reprezint cazul de utilizare a diagramei, strutura de baz poate include numai doi actori i un singur caz de utilizare (Fig. 8).

48

Figura 8. Diagrama cazurilor de utilizare

Conform cerinelor, la vinderea mrfurilor, un vnztor poate participa n formarea a ctor-va comenzi, n acelai timp fiecare comand poate fi format numai de un singur vnztor, care are responsabilitatea pentru corectitudinea formrii lui i respectiv va avea rsplat pentru formarea dat. Din alt parte, fiecare cumprtor poate forma cteva comenzi i n acelai timp fiecare comand trebuie s fie format la un singur cumprtor, care va avea drepturile de proprietate la marf dup achiziionarea ei. Etapa urmtoare n diagrama dat este A perfecta comanda de cumprare a mrfii poate fi precizat pe baza ntroducerii a patru cazuri de utilizare adugtoare. Acest lucru este evident din analiza mai detaliat a procesului de vindere a mrfii, ce permite de alege ca servicii separate acele aciuni ca asigurarea cumpratorului cu informaia despre marf, coordonarea condiiilor de plat i comandarea mrfii de la depozit. Evident c aciunile indicate desfoar comportamentul cazului de utilizare iniial i anume concretizarea lui i de aceea ntre ele v-a exista relaia de tip include. n cazul nostru catalogul cu mrfuri poate fi comandat de cumprtor sau vnztor cnd apare necesitatea de a alege marfa i precizarea detaliilor de vindere. Corect este reprezentat serviciul Cererea catalogului cu mrfuri ca caz de utilizare independent. Detalizarea poate fi executat pe baza indicrii relaiilor adugtoare de tipul relaiei generalizare pentru componentele diagramei deja existente. n sistemul de vindere a mrfurilor poate avea valoarea independent i proprietile specifice o categorie independent de mrfuri calculatoare. n acest caz n diagram poate fi adugat un caz de utilizare Perfectarea comenzii de achiziionare a calculatorului i
49

cu actori Cumprator de calculatoare i Vnztor de calculatoare, care sunt legate cu componentele corespunztoare a diagramei relaiei de generalizare (Fig. 9).

Figura 9. Diagrama cazurilor de utilizare

Construirea diagramei cazurilor de utilizare este prima etap n procesul analizei obiect orientate i proiectare, scopul creia este reprezentarea totalitii de cereri la comportamentul sistemului proiectat. Specificaia de cereri la sistemul proiectat n form de diagram a cazurilor de utilizare reprezint un model independent, care se numete modelul cazurilor de utilizare n limbajul UML i are un nume propriu stanadard sau steriotip UseCaseModel.

Lucrare de laborator nr. 3

Tema: Diagrama de clase Scopul: 1. Identificarea conceptelor domeniului (analiza domeniului) 2. Selectarea claselor i determinarea tipului ei (boundary, entity, controler) 3. Identificarea relaiilor dintre clase (dependene, asociere, generalizare) 4. Realizarea diagramei de clase
50

Clase, obiecte i relaiile lor n modelarea orientat-obiect elementele primare de modelare sunt clasele, obiectele i relaiile dintre ele. Cnd ncercm s descriem un sistem, folosim clase i obiecte , pentru a modela ce este n sistem (entitile) i relaii pentru a preciza modul n care acestea sunt structurate. Clase i obiecte Un obiect este o entitate despre care putem vorbi i pe care o putem gestiona. O clas este o descriere a proprietilor i comportamentului unui tip obiect. Toate obiectele sunt instane ale claselor; un obiect joac un rol similar cu al unei variabile de un anumit tip ntr-un limbaj de programare. Diagrama de clase. Pentru a descrie static un sistem vom construi diagrama claselor, care constituie punctul de plecare n construirea altor tipuri de diagrame, construite pentru a surprinde alte aspecte ale sistemului, cum ar fi strile obiectelor sau colaborrile dintre obiecte. Modelul de domeniu este creat cu scopul de a reprezenta vocabularul i conceptelecheie ale domeniului problemei. Modelul de domeniu identific, de asemenea, relaiile dintre toate entitile n sfera de aplicare a domeniului problemei, i identific de obicei atributele lor. Identificarea conceptelor domeniului Exemplu: s ne referim la cazurile de utilizare specificate n imagine.

a. Cautarea lucrrilor

51

Pentru acest caz, vom identifica urmatoarele concepte fundamentale: lucrarea, autorul, editorul. b. Gestiunea coului n "Gestiunea cosului" exista urmatoarele concepte fundamentale: coul, cartea. c. Efectuarea comenzii "Efectuarea comenzii" lucreaz cu urmtoarele concepte fundamentale: comanda, coul, clientul, cartea de credit. Observatie Modelarea nu tolereaza utilizarea mai multor nume pentru acelai concept. n cazul nostru "lucrare " este sinonim cu "carte". Definiii 1. Clasa - reprezinta descrierea abstracta a unui ansamblu de obiecte avnd aceleai caracteristici. 2.Obiectul - este o entitate cu limite bine definite, avnd o identitate i nglobnd o stare i un comportament. Un obiect este o instan a unei clase. 3.Atributul - reprezint un tip de informaie continut ntr-o clasa. Exemplu: viteza, numarul de nmatriculare, sunt atribute ale clasei "Autoturism". 4.Asocierea- este o relatie semantica durabila ntre doua clase. Exemplu: o persoana poate avea un autoturism. Asocierea ntre concepte este implicit bidirectionala (un automobil poate fi posedat de o persoana). 5.Operatia- reprezinta un element de comportament (un serviciu) continut ntro clasa. Elementele unei clase sunt: Nume - prin care se distinge de alte clase - o clas poate fi desenat artndu-i numai numele; Atribute - reprezint numele unor proprieti ale clasei;
52

 Operaii (metode) - reprezint implementarea unor servicii care pot fi cerute oricrui obiect al clasei. Notaia grafic pentru clas poate fi observat n Fig. 1.

Figura 1. Notaia grafic pentru clas

Specificatorii de vizibilitate au urmtoarea semnificaie: + public (dreptul de utilizare se acord i celorlalte clase); - private (numai clasa dat poate folosi atributul sau operaia); # protected (posibilitatea de utilizare este accesibil numai claselor succesoare) Selectarea claselor. Selectarea claselor necesit anumite deprinderi ce in de filtrarea substantivelor care nu vor reprezenta clase, ci poate doar atribute sau operaii ale unor clase. Aceast filtrare presupune eliminarea claselor candidat care au una din urmtoarele caracteristici: -este redundant: exist deja un sinonim n modelul domeniului; -este irelevant: substantivul nu este relevant pentru sistemul dat; -este un atribut: ncapsuleaz o singur valoare i nu intereseaz n studiul respectiv nici un comportament specific; -este o operaie: substantivul corespunde unui atribut calculat (ex. Valoarea_totala n clasa Comand); -este un eveniment: (ex. Generarea rapoartelor are loc lunar). Observatie Cea mai frecventa eroare la selectarea claselor este acela de a reprezenta ceva ca pe un atribut n loc de concept, daca nu putem cere unei entitati dect valoarea sa, atunci

53

acea entitate este un atribut; daca i putem pune mai multe ntrebari, atunci avem de-a face cu un concept care are la rndul sau mai multe atribute i legaturi cu alte obiecte. Exist trei tipuri de clase (marcate n UML ca stereotipuri): Clase entiti (sau clase de domeniu) reprezint nucleul unei aplicaii, rein informaile legate de entitile persistente i captureaz serviciile ce conduc majoritatea interaciunilor in aplicaie. De obicei clasele entitate trebuie s: -inmagazineze i reda valori de atribute; -creeze i s tearg entiti; -furnizeze un comportament dependent de modificarea strii entitii. Clase de interfa reprezint grania dintre actorii care doresc s interacioneze cu aplicaia i clasele entitate. Majoritatea sunt componente ale interfeei utilizator (fiecare cutie de dialog este o clasa interfa), modeleaz comunicarea cu alte aplicaii sau reprezint clase wrapper peste anumite componente soft. Se determin studiind: -modul n care doresc actorii s creeze entiti; -interfaa ntre aplicaie i alte sisteme; -modalitatea de vizualizare a informaiilor (rapoarte). Clase de control (controller) coordoneaz activitatea n interiorul aplicaiei. Se ceeaz cte o clas controller pentru fiecare caz de utilizare. Pot juca unul din urmtoarele roluri: -modelarea unui comportament tranzacional; -secven de control specific unuia sau mai multor cazuri de utilizare; -serviciu ce separ obiectele entitate de obiectele de interfa. Identificarea relaiilor dintre clase. La identificarea claselor se observ c puine din ele au sens singure. Majoritatea claselor colaboreaz unele cu altele n moduri diferite, aa nct la modelarea unui sistem pe lng identificarea claselor trebuie identificate i relaiile dintre acestea.
54

Indentificarea claselor nu poate fi separat, ca moment n timp, de identificarea relaiilor dintre acestea deoarece, nelegerea relaiilor ajut la rafinarea claselor. Relaii. O relaie modeleaz o conexiune semantic sau o interaciune ntre elementele pe care le conecteaz. n modelarea orientat obiect cele mai importante relaii sunt relaiile de asociere, dependena, generalizare i realizare. Un caz particular al relaiei de asociere l constituie relaia de agregare. ntre clase se pot stabili relaii de generalizare, dependen i realizare. Relaiile de asociere i agregare se stabilesc ntre instane ale claselor (Fig. 2).

Figura 2. Notaii grafice pentru diferite tipuri de relaii: a)asociere bidirecional; b)asociere unidirecional; c) agregare; d) dependen; e) generalizare, f) realizare

Relaia de asociere Relaia de asociere exprim o conexiune semantic sau o interaciune ntre obiecte aparinnd unor anumite clase. Asocierea poart informaii despre legturile dintre obiectele unui sistem. Pe msur ce sistemul evolueaz, pot fi create legturi noi ntre obiecte sau pot fi distruse legturile existente. Relaia de asociere ofer baza arhitectural pentru modelarea conlucrrii i interaciunii dintre clase. O asociere interacioneaz cu obiectele sale prin intermediul capetelor de asociere. Capetele de asociere pot avea nume, cunoscute sub denumirea de roluri, i vizibilitate, ce specific modul n care se poate naviga nspre respectivul capt de asociere. Cea mai important caracteristic a lor este multiplicitatea, ce specific cte instane ale unei clase corespund unei singure instane a altei clase. De obicei multiplicitatea este folosit pentru asociaiile binare. Reprezentarea grafic a asocierii
55

este o linie ce conecteaz clasele ce particip n asociere. Numele asocierii este plasat pe linie, iar multiplicitatea i rolurile sunt plasate la extremitile sale (Fig. 3).

Figura 3. Notaia grafic detaliat a relaiei de asociere

Observaie. Numele rolurilor pot fi omise (eventual i numele asocierii) Este posibil specificarea direciei unei asocieri, pentru a elimina legturi redundante sau irelevante pentru un anumit model. n aceast situaie notaia grafic pentru relaia de asociere este o linie cu o sgeat la unul din capete indicnd direcia asocierii (Fig. 2b). Relaia de agregare Relaia de agregare este o asociere ce modeleaz o relaie parte-ntreg. Este reprezentat ca un romb gol ataat la captul asocierii de lng clasa agregat (Fig. 2c). n figur o instan a clasei A conine o instan a clasei B (altfel spus un obiect B este o parte unui obiect A). Relaia de agregare este deci un caz particular al relaiei de asociere. Ea poate avea toate elementele unei relaii de asociere, ns n general se specific numai multiplicitatea. Se folosete pentru a modela situaiile n care un obiect este format din mai multe componente. Compoziia este o form mai puternic a agregrii. Partea are timpul de via al ntregului. ntregul poate avea responsabilitatea direct pentru crearea sau distrugerea prii sau poate accepta o alt parte creat i mai apoi s paseze responsabilitatea altui ntreg. n Figura 4 este prezentat un exemplu n care se folosete agregarea i compoziia.

56

Figura 4 Exemplu de relaii de agregare i compoziie

Relaia de dependen. O dependen (Fig. 2d) indic o relaie semantic ntre dou elemente ale modelului. Se folosete n situaia n care o schimbare n elementul destinaie (B) poate atrage dup sine o schimbare n elementul surs (A). Aceast relaie modeleaz interdependenele ce apar la implementare (vezi ex. din Fig. 5).

Figura 5. Exemplu de relaii de dependen

Relaia de generalizare. Relaia de generalizare (Fig. 2e) se folosete pentru a modela conceptul de motenire ntre clase. n figur clasa A este derivat din clasa B. Spunem c A este clasa derivat (sau subclasa, sau clasa copil), iar B este clasa de baza (sau superclasa, sau clasa printe). Relaia de generalizare mai poart denumirea de relaie de tip is a (este un fel de), n sensul c o instan a clasei derivate A este n acelai timp o instan a clasei de baz B (clasa A este un caz particular al clasei B sau, altfel spus, clasa B este o generalizare a clasei A). Clasa A motenete toate atributele i metodele clasei B. Ea poate aduga noi atribute sau metode sau le poate redefini pe cele existente (vezi ex. din Fig. 6).

57

Figura 6. Exemplu de relaie de generalizare

Relaia de realizare. Relaia de realizare (Fig. 2f) se folosete n cazul n care o clas (A) implementeaz o interfa (B). Se spune c A realizeaz interfaa specificat de B. O interfa este o specificare comportamental fr o implementare asociat. O clas include o implementare. Una sau mai multe clase pot realiza o interfa prin implementarea metodelor definite de acea interfa (vezi ex. din Fig. 7).

Figura 7. Exemplu de relaie de realizare.

n Fig. 8 sunt prezentate dou diagrame de clase n care se folosesc toate tipurile de relaii prezentate mai nainte.

58

Figura 7. Dou diagrame de clase n care se folosesc toate tipurile de relaii.

59

Lucrare de laborator nr. 4 Tema: Diagrama de interaciuni (diagrama de secven/colaborare) Scopul: 1. determinarea scenariilor 2. obiectele ce particip la interaciune 3. mesajele (sincrone, asincrone) 4. elaborarea diagramei de secven 5. fragmente de reprezentare n diagrama de secven 6. elaborarea diagramei de colaborare Dup nelegerea domeniului problemei (prin realizarea modelului domeniului) i a cerinelor sistemului (prin realizarea modelului cazurilor de utilizare), se poate trece la etapa de proiectare a sistemului, respectiv realizarea modelului proiectrii, prin introducerea de concepte specifice programrii. Modelul proiectrii descrie att structura intern a sistemului (lase, obiecte i relaii), ct i colaborrile care intevin cnd obiectele transmit mesaje pentru arealiza funcionalitatea dorit. Structura static este descris n diagrame de clase, iar dinamica sistemului este descris prin diagrame de interaciune. Aceste grupuri de diagrame au ca elemente comunemetodele claselor.prin urmare, o modalitate de verificare a modelului proiectrii este aceea de a se asigura corespondena metodelor descrise n diferite diagrame Diagramele de interaciune arat cum conlucreaz obiecteleprin transmiterea de mesaje pentru a satisface cerinele sistemului. Exist dou tipuri de diagrame de interaciune diagrama de colaborare i diagrama de secven. ntre cele dou tipuri de diagrame nu exist diferene majore: diagramele de secven scot n eviden ordinea n timp a mesajelor, iar diagramele de colaborarescot n eviden legturile dintre obiecte.
60

Diagrama de interaciuni ilustreaz cum interacioneaz obiectele ntre ele cu ajutorul mesajelor. Folosit pentru a modela comportamentul unei mulimi de obiecte dintr-un anumit context, care interacioneaz n vederea ndeplinirii unui anumit scop. Scop: specific modul n care se realizeaz o operaie sau un caz de utilizare. Diagrama de interaciuni poate conine: - obiecte, actori clase; - relaii; - mesaje. Obiectele: -pot fi lucruri concrete sau prototipuri -ntre ele se pot stabili conexiuni semantice (legturi) -comunic ntre ele prin schimburi de mesaje Mesaj: -Specific o comunicare ntre obiecte -i este asociat o aciune care poate avea ca efect schimbarea strii actuale a obiectului -Forma general a unui mesaj: [cond gard] aciune (lista parametrilor) Tipuri de aciuni n UML - call: invoc o operaie a unui obiect. - return: returneaz o valoare apelantului - send: trimite un semnal - create: creeaz un obiect - destroy: distruge un obiect Exist dou tipuri de diagrame de interaciuni: diagrama de secven i diagrama de colaborare. Diagrama de secven pune accentul pe aspectul temporal (ordonarea n timp a mesajelor)
61

Notaie grafic: 1. dimensiunea orizontal (axa ox): obiecte 2. dimensiunea vertical (axa oy): - linia vieii obiectelor (grafic: linie punctat) - perioada de activare n care un obiect preia controlul execuiei (grafic: dreptunghi pe linia vieii) -mesaje ordonate n timp (grafic: sgei)

Comunicare sincron. Controlul execuiei trece de la A la B i revine la A dup ce B i termin execuia. Exemplu: apel de funcie. Comunicare asincron. A trimite un semnal dup care i continu execuia mai departe. Exemplu: aruncarea unei excepii. Return. ntoarcere dintr-o funcie (procedur). n cazul n care este omis se consider implicit c revenirea se face la sfritul activrii.

62

Ramificaii este reprezentarea mai multor mesaje care pleac din acelai punct i sunt etichetate cu o condiie: - condiii mutual exclusive condiionalitate (if, switch) - condiii care se suprapun concuren

Iteraii - Indic faptul c un mesaj (o mulime de mesaje) se repet - Mesajul este etichetat cu o condiie gard de forma: *[cond] aciune(lista parametrilor)

63

- Dac sunt mai multe mesaje acestea vor fi.nconjurate cu un chenar; n interiorul chenarului va fi specificat condiia (*[cond]).

Fragmente combinate (combined fragment) Fragmentele combinate (combined fragment) sunt elementele modelului, prevzute pentru reprezentarea structurii logice interne a interaciunii dintre fragmente. Operand de interaciune (interaction operand) este un fragment special al interaciunii, destinat utilizrii ca parte intern a fragmentului combinat. Constrngere de interaciune (interaction constraint) este o expresie logic, care acioneaz ca condiie de gard ai unor operanzi ntr-un fragment combinat.

64

Operator de interaciune (interaction operator)- determin tipul fragmentului combinat, se desting 12 operatori: 1. alt 2. break 3. ignore 4. loop 5. opt 6. seq 7. assert 8. critical 9. consider 10. neg 11. par 12. strict

Vom examina civa dintre ei: Operatorul de interaciune alt al fragmentului combinat specific alternative de interaciune (alternatives), ce reprezinta o alegere a comportamentului. La alegere particip numai unul din operanzi. Operandul selectat, trebuie s aib o condiie de gard explicit sau implicit, care la acest punct de interaciune trebuie s ia valoarea true. n cazul n care, operandul nu are nici o condiie de gard, atunci implicit se
65

presupune c condiia de gard are valoarea true. Operandul marcat cu condiia de gard [else], denot negarea disjunciei celorlalte condiii de gard al acestui fragment combinat.

Operatorul de interaciune break specific fragmentul combinat sfrit (break), ceea ce reprezint un scenariu de sfrit. Acest scenariu se execut n locul fragmentului de interaciune ramas, care conine acest operand corespunzator. De obicei, operatorul break conine o condiie de gard. Dac aceasta condiie de gard ia valoarea true atunci se execut fragmentul combinat break, iar restul fragmentului de interaciune ce conine acest operand este ignorat. n cazul n care condiia de gard ia valoarea false atunci operandul sfrit este ignorat i se execut restul fragmentului de interaciune care conine acest operand.

66

 Operatorul de interaciune critical specific fragmentul combinat al regiunii critice (critical region), traiectoriile crora nu pot alterna cu alte specificaii de evenimente pe acele linii de via, care acoper aceast regiune. Regiunea critic este tratat ca indivizibil n determinarea setului de traiectorii posibile ale diagramei sau regiunii pe care aceasta o conine.

67

 Setul de traiectorii ale regiunii critice nu poate fi ntrerupt de alte evenimente, care au loc n afara acestei regiuni. n practic regiunea critica este utilizat, de obicei, mpreun cu operatorul de paralelism par. Diagrama de colaborare - pune accentul pe organizarea structural a obiectelor care particip la interaciune. Ilustreaz mai bine ramificri complexe, iteraii i comportament concurent. Poate conine: obiecte, clase, actori; legturi ntre acestea; mesaje. Exemple de mesaje Simple 2: display(x,y) Subapeluri, inclusiv valoarea de retur 1.3.1: p=find(specs) Condiionale 4 [x<0]: invert(x,color) Iteraii 1 *[i=1..n]: update()

68

Exemplu diagram de colaborare

Lucrare de laborator nr. 5

Tema: Diagrama de activiti i diagrama de stare a obiectelor Scopul: 1. 2. descrierea fluxului de activiti specifice funcionalitii sistemului; descrieria strilor prin care trec unele obiecte.

Pentru modelarea procesului de executare a operaiilor n limbajul UML se utilizeaz aa numitele diagrame de activiti. Grafic diagrama de activiti se reprezint n forma unui graf de activitate cu nodurile stri activitate i muchile tranziii de la o stare la alt. n aa fel, diagramele de activiti pot fi considerate cazuri particulare ale diagramelor de stri. Anume aceste diagrame permit realizarea administrrii procedurale i sincrone care depinde de terminarea activitii interne n limbajul UML. Sensul principal al utilizrii acestor diagrame const n vizualizarea
69

particularitilor operaiilor unor clase pentru reprezentarea algoritmilor executrii lor. Totodat fiecare stare realizeaz operaiile unei clase anumite i permite utilizarea diagramei de activiti pentru descrierea reaciilor la evenimente interne acestui sistem. n contextul limbajului UML activitatea (activity) reprezint o totalitate de calcule executate de ctre automat. Totodat calculele elementare pot duce la un anumit rezultat sau careva aciune (action). n diagrama de activiti se reflect logica sau consecutivitatea tranziiilor de la o aciune la alta, totodat se evideniaz rezultatul activitii. Rezultatul, la rndul su poate duce la schimbarea strii sistemului dat sau la returnarea unei valori. Diagrama de activiti este folosit pentru a modela dinamica unui proces sau a unei operaii i scote n eviden controlul execuiei de la o activitate la alta. Diagramele de activiti pot conine: stri activiti i stri aciuni, care sunt stri ale sistemului; tranziii; obiecte; bare de sincronizare; ramificaii. Strile activitate (activity states) - pot fi descompuse, activitatea lor putnd fi reprezentat cu ajutorul altor diagrame de activiti. Strile activitate nu sunt atomice (pot fi ntrerupte de apariia unui eveniment) i au durat (ndeplinirea lor se face ntr-un interval de timp). Strile aciuni (action states) - modeleaz ceva care se ntmpl (de exemplu evaluarea unei expresii, apelul unei operaii a unui obiect, crearea/distrugerea unui obiect). O stare aciune reprezint execuia unei aciuni. Ea nu poate fi descompus. Strile aciuni sunt atomice (nu pot fi ntrerupte chiar dac se produc evenimente) i au o durat nesemnificativ (foarte mic).
70

Notaia grafic a strilor activitate/aciune se poate observa n Fig. 1.

Figura 1. Notaia grafic a strilor activitate/aciune

Tranziiile reprezint relaii ntre dou activiti. Tranziia este iniiat de terminarea primei activiti i are ca efect preluarea controlului execuiei de ctre a doua activitate.

a)

b)

Figura 2. Exemplu de dou activiti unite de o tranziie

n exemplul din Fig. 2b, prima activitate este aceea n care se adaug un client nou. Tranziia la a doua activitate (i anume aceea de a atribui un staff de contact pentru o eventual campanie de promovare) implic faptul ca odat ce prima activitate s-a terminat, a doua activitate este startat. Dac din starea dat iese numai o tranziie atunci ea poate s nu fie marcat (indicat), dar dac tranziiile de ieire sunt mai multe atunci poate s acioneze numai una din ele. Anume n acest caz pentru fiecare din tranziii trebuie s fie indicat n paranteze patrate o condiie de supraveghere. Totodat pentru toate strile de ieire trebuie s fie executat numai o cerin de veridicitate a unei tranziii. Acest caz are loc cnd activitatea consecvent executat trebuie s fie divizat n ramuri alternative independent de valoarea unui rezultat intermediar. Aceast situaie se numete ramificaie. Grafic ramificaie se reprezint printr-un romb gol. n acest romb numai o sgeat de la o aciune corespunztoare poate s intre. Sgeata de intrare se unete cu vrful de sus sau cu cel din stnga al simbolului de ramificaie. Pot fi mai multe sgei de ieire, dar pentru fiecare din ele trebuie s fie indicat condiia de supraveghere sub
71

form de expresie boolean. Fiecare tranziie de ieire trebuie s aib o condiie gard. Condiiile gard trebuie s fie disjuncte (s nu se suprapun) i s acopere toate posibilitile de continuare a execuiei (vezi exemplele din Fig. 3), altfel fluxul de control al execuiei va fi ambiguu (nu se tie pe care cale se va continua execuia). Condiiile trebuie ns s acopere toate posibilitile, altfel sistemul se poate bloca.

Figura 3. Activiti cu puncte de ramificaie

Figura 4. Activiti cu punct de ramificaie i fr punct de ramificaie explicit

Uneori nu este necesar precizarea explicit a unui punct de decizie, pentru a simplifica diagrama (vezi exemplul din Fig. 4).

72

n figurile 3 i 4 apare un alt element al diagramelor de activiti i anume starea final. n general, odat ncheiat ultima activitate dintr-o diagram, trebuie marcat tranziia spre starea final. De asemenea, dup cum se poate observa n figura 9, fiecare diagram de activiti trebuie s nceap cu starea iniial. Bare de sincronizare Exist posibilitatea ca mai multe activiti s se execute n paralel. Pentru sincronizarea acestora se folosesc aa numitele bare de sincronizare. Acestea pot fi de dou feluri: fork - poate avea o tranziie de intrare i dou sau mai multe tranziii de ieire, fiecare tranziie de ieire prezentnd un flux de control independent. Activitile de sub fork sunt concurente. join - reprezint sincronizarea a dou sau mai multor fluxuri de control. La join fiecare flux de control ateapt pn cnd toate celelalte fluxuri de intrare ajung n acel punct. Poate avea dou sau mai multe tranziii de intrare i o singur tranziie de ieire.

Figura 5. Notaia grafic pentru barele de sincronizare

Obiecte. Aciunile sunt realizate de ctre obiecte sau opereaz asupra unor obiecte. Un obiect poate interveni ntr-o diagram de activiti n dou moduri: o operaie a unui obiect poate fi folosit drept nume al unei activiti (Fig. 6a); un obiect poate fi privit ca intrare sau ieire a unei activiti (Fig. 6b). Obiectele pot fi conectate de aciuni prin linii punctate cu o sgeat la unul din capete (orientarea sgeii indic tipul parametrului - intrare sau ieire). Un obiect poate aprea de mai multe ori n cadrul aceleiai diagrame de activiti. Fiecare apariie indic un alt punct (stare) n viaa obiectului. Pentru a distinge apariiile numele strii obiectului poate fi adugat la sfritul numelui obiectului .

73

a)

b)
Figura 6 Diagrama de activiti .a) cu operaia obiectului ca activitate b) cu fluxuri de obiecte

Conceptul de swimlanes modeleaz (arat) activitile care au loc n interiorul unui sistem. Denumirele subdiviziunelor sunt indicate n partea de sus a partiiei. A ntretia linia partiiei pot numai tranzaciile, care n acest caz indic ieirea sau intrarea fluxului de control n subdiviziunea respectiv a companiei. Ordinea trecerii partiiilor nu are care-va informaie simantic i este definit dup motivele de comfortabilitate. Ca exemplu vom lua fragmentul diagramei de activitate a companiei de vindere, care servesc clienii cu ajutorul telefonului. Subdiviziunele companiei sunt secia de acceptare i perfectare a cerinelor, secia de vindere i depozitul. Acestor subdiviziuni vor corespunde trei partiii n diagrama de activitate, fiecare din care specific zona de responsabilitate a subdiviziunei. n diagrama de activitate cu partiii deplasarea obiectelor poate avea un sens adugtor. i anume, dac obiectul este amplasat la hotarul ambilor partiii, aceast
74

lucru nseamn c trecerea la starea de aciune urmtoare n partiia vecin este asociat cu un document finit (obiectul n careva stare). Dar dac obiectul este amplasat nuntrul partiiei, atunci starea acestui obiect este definit de aciunile partiiei date.

Figura 7. Diagram de activiti cu obiecte i swimlanes

Diagrama de stri (State chart Diagram)

75

Comportamentul unui program poate fi descris prin urmtoarele tipuri de diagrame: diagrama de stri diagrama de activiti diagrama de interaciuni: - diagrama de secvene - diagrama de colaborare Diagrama de stri este folosit pentru a modela comportamentul unui singur obiect. Diagrama de stri specific o secven de stri prin care trece un obiect de-a lungul vieii sale ca rspuns la evenimente mpreun cu rspunsul la aceste evenimente. Noiuni preliminare Un eveniment reprezint ceva (atomic) ce se ntmpl la un moment dat i care are ataat o locaie n timp i spaiu. Evenimentele modeleaz apariia unui stimul care poate conduce la efectuarea unei tranziii ntre stri. Evenimentele nu au durat n timp. Evenimentele pot fi clasificate n felul urmtor: sincrone sau asincrone externe sau interne

Evenimentele externe se produc ntre sistem i actori (de exemplu apsarea unui buton pentru ntreruperea execuiei programului). Evenimentele interne se produc ntre obiectele ce alctuiesc un sistem (de exemplu overflow exception). Evenimentele pot include: semnale; semnalul este un stimul asincron care are un nume i care este trimis de un obiect i recepionat de altul (ex: excepii).
76

apeluri de operaii (de obicei sincrone): un obiect invoca o operaie pe un alt obiect; controlul este preluat de obiectul apelat, se efectueaz operaia, obiectul apelat poate trece ntr-o nou stare, dup care se red controlul obiectului apelant.

trecerea timpului o schimbare a rezultatului evalurii unei condiii

O aciune reprezint execuia atomic a unui calcul care are ca efect schimbarea strii sau returnarea unei valori. Aciunile au o durat mic n timp, fiind tranzitorie (ex.: i++). Prin activitate se nelege execuia neatomic a unor aciuni. Activitile au durat n timp, pot persista pe toat durata strii i poate fi ntrerupt (ex.: execuia unei funcii). O diagram de stri poate conine stri i tranziii. Starea Prin stare se nelege o condiie sau situaie din viaa unui obiect n timpul creia acesta: satisface anumite condiii; efectueaz o activitate; ateapt apariia unui eveniment. Notaia grafic pentru stare este prezentat n figura 8.

Figura 8. Notaia grafic pentru stare

Exist dou stri particulare i anume starea iniial i starea final. Starea iniial (Fig. 9a) este starea din care pleac entitatea modelat. Starea final (Fig. 9b) este starea n care entitatea modelat i ncheie existena.
77

Figura 9: Notaii grafice pentru starea iniial (a) i starea final (b)

Elementele care caracterizeaz o stare sunt: Nume - identific n mod unic o stare; numele este reprezentat de o succesiune de iruri de caractere. Aciuni de intrare/ieire - sunt aciuni ce se produc la intrarea, respectiv ieirea din starea respectiv. Substri care pot fi - concurente (simultan active) figura 10a - disjuncte (secvenial active) figura 10b

Figura 10: Notaii grafice pentru substri concurente (a) i disjuncte (b)

obiectului.

Tranziii interne - sunt aciuni i activiti pe care obiectul le execut

ct timp se afl n acea stare; se produc ntre substri i nu produc schimbarea strii

78

Figura 11. Notaia complet pentru stare

Forma general a unei tranziii interne este: nume_eveniment(lista_parametri)[condiie_gard]/aciune unde: nume_eveniment identific circumstanele n care aciunea specificat se execut; condiie_gard condiie boolean care se evalueaz la fiecare apariie a evenimentului specificat; aciunea se execut doar cnd rezultatul evalurii este true; aciunea poate folosi atribute i legturi care sunt vizibile entitii modelate. Dup cum se poate observa din Fig. 11, dou evenimente au notaii speciale: entry i exit. Aceste evenimente nu pot avea condiii gard deoarece se invoc implicit la intrarea, respectiv ieirea din starea respectiv. Activitile sunt precedate de cuvntul cheie do. Pentru a arta c o stare conine substri, se folosete cuvntul cheie include, urmat de numele diagramei substrilor (vezi exemplul din Fig. 12).

Figura 12. Exemplu de stare

Tranziia. O tranziie reprezint o relaie ntre dou stri indicnd faptul c un obiect aflat n prima stare va efectua nite aciuni i apoi va intra n starea a doua
79

atunci cnd un anumit eveniment se petrece. Notaia grafic pentru tranziie se poate observa n Fig. 13.

Figura 13. Notaia grafic pentru tranziie

Starea surs reprezint starea din care se pleac. Eveniment este evenimentul care declaneaz tranziia. Condiie gard (guard condition) este o expresie boolean. Aceasta se evalueaz la producerea evenimentului care declaneaz tranziia. Tranziia poate avea loc numai dac condiia este satisfcut. Aciune - opional se poate specifica o aciune care s se execute odat cu efectuarea tranziiei. Starea destinaie reprezint starea n care ajunge obiectul dup efectuarea tranziiei. n figurile 14 i 15 se pot observa exemple de stri cu substri disjuncte, respectiv concurente.

Figura 14. Exemplu de stare cu substri disjuncte

80

Figura 15. Exemplu de stare cu substri concurente

n Fig. 16 este prezentat un exemplu de diagram de stare pentru un proiect propus de un student.

Figura 16. Diagram de stare

81

Lucrare de laborator nr. 6

Tema: Diagrama de componente Scopul: 1. determinarea componentelor aplicaiei. 2. stabilirea dependenelor ntre componente. 3. determinarea artefactelor Toate diagramele analizate mai sus reflectau aspectele conceptuale de proiectare a unui model de sistem i se referiau la nivelul logic de reprezentare. Specificul reprezentrii logice const n faptul c el utilizeaz noiuni care nu au personificare material proprie. Cu alte cuvinte diferite elemente ale reprezentrii logice (clase, asocieri, stri, mesaje) nu exist n mod material sau fizic. Ele numai reflect nelegerea noastr despre sistemul fizic sau despre aspectele comportamentului acestui sistem. Pentru crearea unui sistem fizic real este necesar a transforma toate elementele reprezentrii logice n entiti materiale. Pentru descrierea acestor entiti este destinat aspectul reprezentrii modelarefizice. Sistemul program poate fi considerat realizat numai n caz daca el va putea executa funciile destinaiei sale. Aceasta este posibil dac codul surs al unui sistem va fi realizat n forma de module executate, biblioteci ale claselor i procedurilor, interfeelor grafice standarde, fiierelor bazelor de date. Anume aceste componente sunt necesare pentru reprezentarea fizic a unui sistem. Proiectul complet al unui sistem al programului reprezint o totalitate de modele ale reprezentrii logice i fizice care sunt coordonate ntre ele. n limbajul UML pentru reprezentarea fizic a unui model al sistem sunt utilizate diagramele de realizare (implementation diagrams) care includ dou diagrame canonice: diagrama de componente i diagrama de desfurare.

82

Pentru reprezentarea entitilor fizice n limbajul UML se utilizeaz componenta (component). Componenta realizeaz un set de interfee i desemneaz elementele reprezentrii fizice a unui model. Grafic componenta se reprezint printrun dreptunghi cu anexe (fig. 1). n nteriorul acestui dreptunghi se indic numele componentei i posibil informaia suplementar. Reprezentarea acestui simbol variaz n dependen de informaia asociat cu componenta dat.

Figura 1. Component.

Urmtorul element a diagramei componentelor sunt interfeele. n cazul general interfaa este reprezentat n form de circumferin, care este legat cu componentul cu ajutorul liniei fr sgeat (Fig. 2, a). n urma cruia numele interfeei, care obligatoriu trebuie s fie scris cu majuscul I, este scris alturi de circumferin. Semantic linia nseamn interfaa, iar prezena interfeelor la componente nseamn c componentul dat realizeaz trus de interfee respective.

Figura 2 Reprezentarea grafic interfeelor n diagrama de componente.

Un alt mod de reprezentare a interfeelor n diagrama de componente este reprezentarea lui n forma de dreptunghi a clasei cu stereotipul interfaa i cu seciuni posibile a atributelor i operaiilor (Fig. 2, b). Ca regul, acest caz de notare este utilizat pentru reprezentarea structurii interne a interfeei, care poate fi important pentru realizarea.

83

Exist dou feluri de legtur a interfeei i componentului. Dac componentul realizeaz o anumit interfa, atunci aceast interfa este numit de export (provided), deoarece acest component prezint n el modul de serviciu pentru altele componente. Dac componentul utilizeaz o anumit interfa, care este realizat de un alt component, atunci acea interfa pentru primul component este numit de import (required ). Particularitile interfeei de import const n aceea c n diagrama de componente aceast relaie este reprezentat cu ajutorul dependenei. Relaia de dependen n diagrama de componente reprezint o linie punctir cu sgeat orientat de la client (element dependent) la surs (element independent). Relaia poate indica legturile modulelor programului la etapa de compilare i generare a codului. n alt caz dependena poate indica existena n componentul independent descrierea clasei, care sunt utilizate n componentul dependent pentru crearea obiectelor respective. n diagrama de componente dependenele pot conecta componentele i interfeele de import de component, dar i diferite feluri de componente ntre sine. n primul caz se deseaneaz sgeat de la component client la interfaa de import (Fig. 3). Prezena sgeii nseamn c componetul nu realizeaz interfaa respectiv, dar utilizeaz n ea procesul su de executare. n aceast diagram mai poate exista i un alt component, care realizeaz aceast interfa. De exepmplu, fragmentul diagramei de componente prezentat mai jos reprezint o informaie despre componentul cu numele main.exe dependent de interfaa de import I dialog, care la rndul su este realizat de componentul cu numele image.java. Pentru al doilea component aceai interfa este de export

Figura 3. Fragmentul diagrameide componente cu relaie de dependena. 84

Dac este necesar de subliniat c care-va component realizeaz anumite clase, atunci pentru indicarea componentului este utilizat simbolul n form de dreptunghi. n urma cruia dreptunghiul componentului divizeaz n dou seciuni cu linia orizontal. Secia de sus este utilizat pentru notarea numelui componentului, iar cea de jos pentru indicarea informaiei adugtoare (Fig. 4).

Fig. 4. Reprezentarea grafic a componentului cu informaia adugtoare despre clase realizate.

nuntrul simbolului a componentului sunt indicate alte elemente a notaiei grafice, aa clase ca (componentele nivelului de tip) sau obiectele (componentele nivelului de exemplare). n acest caz simbolul componentului este reprezentat n aa fel ca s ntroduc aceste simboluri adugtoare. De exemplu, componentul realizat mai jos (Fig. 5 ) este exemplar i realizeaz trei obiecte.

Figura 5. Reprezentarea grafic a componentului nivelului de exemplar, ce realizeaz obiectele.

Obiecte, care se afl n componentul exemplar sunt reprezentate ntr-un fel de elementele depuse n simbolul componentului dat. Aa fel de depunere nseamn c efectuarea componentului duce la executarea obiectelor respective. Instrumentul Rational Rose introduce o serie de stereotipuri predefinite pentru componente (Fig. 6 ):
85

Dialog.dll

Index.html

Context .hlp

Main.cpp

Figura 6. Variantele reprezentrii grafice a componentelor diagramei de componente

Aceste elemente sunt uneori numite artefacte, subliniaz n aa fel coninutul lor informaional finit, dependent de tehnologie de realizare concret a componentelor respective. Mai mult dect att, elaboratorii pentru acest scop pot utiliza notaii independente, deoarece n limbajul UML nu exist notare strict pentru reprezentarea grafic a notaiilor. Recomandri la construirea diagramei de componente Elaborarea diagramei de componente presupune utilizarea informaiei despre reprezentarea logic a modelului sistemului, dar i despre particularitile realizrii ei fizice. nainte de elaborare este necesar de a face o decizie despre alegerea programei de calcul i sistemului operaional, dup care s realizm sistemul, dar i alegerea bazelor de date concrete i limbajelor de programare. Dup care ajungem la structurizarea general a diagramei de componente. n primul rnd este necesar de a hotr din care pri (fiiere) fizice va fi compus sistemul de programare. Etapa final de construire a diagramei de componente este legat de stabilirea i depunerea n diagram a nteraciunilor ntre componente i relaiile de realizare. Aceste relaii trebuie desfurate n toate aspectele importante a realizrii fizice a sistemului, ncepnd cu particularitile compilrii textelor iniiale a programului i terminnd cu ndeplinirea unor pri a programului la etapa de executare. Pentru aceast scop pot fi utilizate diferite feluri de reprezentare grafic a componentelor. Dar dac proiectul conine anumite elemente fizice, descrierea crora lipsete n limbajul UML,
86

atunci trebuie de utilizat mecanizmul de extindere. i anume, utilizarea stereotipuri adugtoare pentru unele componente netipice sau valorile marcate pentru precizarea unor caracteristici a lor. n sfrit, trebuie de atras atenia c diagrama de componente este, ca regul, elaborat cu diagrama de plasare, care reprezint informaia despre deplasarea fizic a componentelor sistemului a programei dup nodurile ei. Particularitile construirii diagramei de plasare vor fi definite n capitolul urmtor. Etapa de implementare a sistemului presupune un efort de modelare, prin realizarea modelului componentelor.Modulele de cod de diferite tipuri i fiierele binare pot fi descrise prin prisma claselor coninute i a dependenelor ntre ele n diagrame ale componentelor. Etapa de instalare a sistemului presupune realizarea modelului de desfurare, prin prezentarea nodurilor folosite, a modurilor n care acestea sunt conectate, precum i a componentelor ce se vor executa pe fiecare nod (de exemplu ce program sau serviciu este executat pe fiecare calculator). Acest model a1 sistemului prezint interes pentru dezvoltatori i pentru cei care realizeaza testarea sistemului, fiind realizat cu ajutorul diagramelor de desfurare. Diagramele de componente sunt diagrame ce descriu arhitectura codului, prin prezentarea componentelor unei aplicaii i a dependentelor dintre acestea (Fig. 7). Termenul de component reda orice unitate de program (cod sursa, fiier executabil, biblioteca de functii, machete realizate n generatoare de rapoarte) sau documente (Word, Excel), care ndeplinesc funcii n cadrul sistemului informatic. Diagramele de componenete sunt importante deoarece: o Modeleaz sistemul software real n mediul de implementare. o Evidentiaz probleme de configurare prin relaiile de dependen o Reprezint o imagine a sistemului existent, nainte de a fi modificat

87

o Pot evidenia probleme de implementare fr a fi necesar s se citeasc tot codul sursa

Figura 6. Diagramele de componente.

Exist dou tipuri de interfee: - Provided interfaces: aceste interfee descru servicii pe care instanele unui clasificator (furnizor) le ofer clienilor. - Required interfaces: aceste interfee specifica serviciile de care are nevoie un clasificator pentru ai ndeplini funciile i obligaiile sale fa de clienii. Aceste relaii de dependen ne arat modul cum sunt ndeplinite fiecare cerine funcionale ale componentelor de ctre alte componente, precum i modul n care sistemul n ansamblul este capabil s execute lucrrile necesare. Dependenele ntre componente se reprezinta grafic prin linii ntrerupte ntre o component client i o component furnizor de servicii, orientate spre componenta furnizor. Relatia de dependeta semnifica faptul ca clasele incluse n componenta client pot moteni, instania sau utiliza clase incluse n componenta furnizor (sau server). De asemenea, pot exista relaii de dependen ntre componente i interfee ale altor componente, relaii care semnific faptul ca clientul utilizeaz operaii ale componentei server.

88

Lucrare de laborator nr. 7

Tema: Diagrama de desfurare Scopul: 1. determinarea nodurilor. 2. stabilirea relaiilor dintre noduri. 3. distribuirea componentelor n noduri Reprezentarea fizic a sistemului nu poate fi plin, dac lipsete informaia despre programele i metodele de realizare a calculului. Dac este elaborat un simplu program, care poate fi executat local la calculatorul utilizatorului fr ntroducearea echipamentelor periferice i resurselor, atunci n acest caz nu este necesitate de a elabora diagrame adugtoare. ns sistemele de programare compuse pot fi realizate n form de reea n diferite programe de calcul i tehnologii de accesare la bazele de date. Prezena reelei locale corporative necesit rezolvarea totalitii de probleme adugtoare despre amplasarea raional a componentelor dup nodurile reelei, ce definesc producerea general a sistemului. Integrarea sistemului (aplicaie) n Internet, necesit asigurarea securitii, i accesul stabil la informaie pentru clienii corporativi. Aceste aspecte depind mult de realizarea proiectului n form de noduri a sistemului, care exist fizic, aa ca serveri, canale de conectare i pstrrile de date. Diagrama de componente este prima diagrama a reprezentrii fizice. A doua form de reprezentarea fizic a sistemului este diagrama de desfurare. Ea este utilizat pentru reprezentarea general a configurrii i topologiei sistemului i conine repartizarea componentelor dup nodurile sistemului. Scopurile, ce sunt urmrite n timpul elaborrii diagramei de desfurare: o De definit distribuirea componentelor a sistemului dup nodurile fizice.

89

o De prezentat legturile fizice ntre toate nodurile de realizare a sistemului la etapa de executare. o De a gsi locurile nguste a sistemului i de a reconfigura topologia ei pentru atingerea producerii necesare. o Pentru garantarea cerinelor diagramei de desfurare se elaboreaz mpreun cu analitii sistemului, ingineri de reea i alii. Nodul (node) reprezint un element fizic a sitemului, care are o anumit resurs. Reprezentaea grafic a nodului n diagrama de desfurare este n form de cub. Nodul are un nume propriu, care este indicat nuntrul acestui simbol grafic. Nodurile pot fi prezentate n form de tipuri (fig. 1 a), dar i n calitate de exemplare (fig. 1, b).

Fig. 1. Reprezentarea grafic a nodului n diagrama de plasare.

n primul caz numele nodului este scris fr subliniere i ncepe cu majuscul. n al doilea caz numele nodului exemplar este scris n form de <numele nodului ':' numele tipului nodului>. n desenul din (Fig. 1, a) nodul cu numele Server se refer la tipul general i nu se concretizeaz. Al doilea nod (Fig. 1, b) este nodul exemplar anonim a modelului concret a imprimantei. La fel ca n diagrama de componente reprezentarea nodurilor poate fi extins pentru includerea informaiei adugtoare despre specificarea nodului. Dac informaia adugtoare este legat cu numele nodului, atunci ea este scris mai jos de nume ca valoare marcat (Fig. 2).

90

Figura 2. Reprezentarea grafic a nodului exemplar cu informaie adugtoare ca valoare marcat.

Dac este necesar de indicat componentele, care sunt plasate n noduri separate, atunci pentru aceasta exist dou moduri. Primul d posibilitate de a mpri simbolul grafic n dou secii cu linie orizontal. n seciunea cea de sus este scris numele nodului, iar n cea de jos componente de plasat la nodul dat (Fig. 3a). Al doilea mod permite de plasat n diagrama de desfurare nodurile cu componentele depuse (Fig. 3b). Ca componente depuse pot fi numai componentele executabile.

Figura 3. Reprezentarea grafic a nodurilor exemplare cu componentele deplasate.

Ca adugare la numele nodului pot fi utilizate diferite stereotipuri, care specific destinaia nodului. Dei n limbajul UML stereotipuri pentru noduri nu sunt specificate, n literatur exist urmtoarele variante: procesorul, modem, reea i altele, care pot fi specificate de elaborator. Mai mult dect att, n diagramele de desfurare pot fi indicaii speciale pentru diferite echipamente fizice, reprezentarea grafic clarific destinaia sau funciile lor.

91

Pe lng reprezentarea nodurilor n diagrama de desfurare sunt indicate i relaiile ntre ele. n calitate de relaii sunt conectri fizice ntre noduri i dependena ntre noduri i componente. Conectrile sunt un fel de asociere i sunt prezentate n form de linii fr sgei. Prezena liniei indic necesitatea organizrii canalului fizic pentru schimbarea informaiei ntre nodurile respective. Caracter de conectare poate fi adugtor specificat de adnotare, indicat de valoare sau restricie. n fragmentul prezentat mai jos n diagrama de desfurare (Fig. 4) sunt specificate nu numai cererea la viteza de transfer a datelor n reea local cu ajutorul valorii indicate, dar i recomandarea la tehnologia fizic a realizrii conexelor n form de adnotare.

Figura 4. Diagrama de desfurare cu recomandare n form de adnotare

n afar de conectri n diagrama de desfurare pot fi relaiile de dependen ntre nod i componentele lui. Acest caz este alternativ pentru reprezentarea componentelor depuse nuntrul simbolului nodului, ce nu este ntodeauna comod, deoarece simbolul devine valoros. De aceea cnd exist mulimea de componente desfurate n nod, o informaie respectiv poate fi reprezentat n fel de relaie de dependen (Fig. 5). Diagrama de desfurare poate avea o structur mai compus, care include componentele, interfee i alte echipamente. n diagrama de desfurare din (Fig. 6) este prezentat fragmentul reprezentrii fizice a sistemului serviciului ndreptat pentru clienii bncii. Nodurile acestui sistem sunt terminalul deprtat (nodul - tip) i serverul bncii (nodul - exemplar).

92

Figura 5. Diagrama de desfurare cu relaia de dependen ntre nod i componenii desfurrii n el.

n aceast diagram de desfurare este indicat dependena componentul de realizare a dialogului dialog.exe n terminalul deprtat de interfaa Iuthorise, realizat de componentele main.exe, care la rndul su se desfoar la nodul exemplar anonim Serverul bncii. Ultimul depinde de componentul bazei de date Clienii bncii, care de asemenea este desfurat la acest nod. Adnotarea indic necesitatea utilizrii liniei protejate de comunicare pentru schimbarea datelor n sistemul dat.

Figura 6. Diagrama de desfurare pentru sistemul serviciului ndreptat clienelor bncii.

Elaborarea diagramei de desfurare ncepe cu identificarea tuturor tipurilor de echipamente, care sunt necesare pentru executarea de ctre sistem a funciilor sale. n primul rnd sunt specificate nodurile sistemului, ce conin memorie i/sau procesorul. n urma cruia sunt utilizate steriotipuri a limbajului UML, iar n cazul lipsei lor, elaboratorii pot specifica stereotipuri noi. Etapa urmtoare const n plasarea tuturor componentelor executabile a diagramei n nodurile sistemului. Ca regul, elaborarea diagramei de desfurare este realizat la etapa final, ceea ce caracterizeaz sfiritul fazei de proiectare reprezentrii fizice. Din alt parte,
93

diagrama de desfurare poate fi construit pentru analiza sistemului respectiv cu scopul analizei i modificrii urmtoare. n urma cruia analiza presupune elaborarea acestei diagrame la etapa ei iniial, ce caracterizeaz direcia general analizei de la reprezentarea fizic la logic. Diagrama de implementare, din Fig. 7, simbolizeaz existenta, n cadrul unei aplicaii client, a unui modul principal, ce se conecteaza la o baza de date aflata pe un alt calculator, prin intermediul unei biblioteci specifice, pentru a raspunde cererilor formulate de anumite biblioteci ce implementeaz diverse operaii. Conform aceleiai diagrame, la acest server de baze de date se conecteaz o aplicaie web, care poate fi apelat de utilizatori doar prin intermediul unui browser.

Figura 7. Diagrama de desfurare.

94

Bibliografie
1. http://www.uml.org/ 2. http://inf.ucv.ro/~giurca/courses/CB3105/resources/ Introducere in UML.pdf 3. http://www.itzone.ro/articolDisplay.php?id=38&categorie_id=0 4. http://www.scribd.com/fullscreen/47113906 5. http://www.racai.ro/Referate/referat_2_Bizoi_web.pdf 6. http://discipline.elcom.pub.ro/isc/Curs_ISC_2011_2_v01.pdf 7. http://www.bazededate.org/ModelulUnificat.pdf 8. http://software.ucv.ro/~eganea/OOP_index.html 9. https://sites.google.com/site/codrutaistin/laborator-fis-5 10.http://www.scritube.com/stiinta/informatica/INGINERIA-PROGRAMARIIInstant-10423211617.php 11. http://oop.xhost.ro/ip/cursuri.html 12. http://www.scribd.com/doc/46265644/Ingineria-programarii-Faza-de-analiza 13. http://users.cs.tuiasi.ro/~fleon/Curs_IP/IP09_SC1.pdf 14. http://www.geocities.ws/luciweb/c/ip_toc.html 15. http://www.cartigratis.eu/carte/250441/ingineria-programarii-diagrame-uml

95

Anexe
A1. Teme pentru laborator 1. Buletin de stiri (newsletter) 2. Bursa locurilor de munca 3. Motor de testare i evaluare 4. Sistem de gestiune a invatarii 5. Magazin virtual (de un anumit tip) 6. Reea sociala profesional 7. Aplicaie de gestiune a evenimentelor culturale 8. Sistem de gestiune a cunotinelor (de un anumit tip) 9. Aplicaie de localizare a serviciilor de pe un dispozitiv mobil 10. Aplicaie de gestiune a unui program muzical (playlist) 11. Aplicaie de planificare a calatoriilor 12. Sistem rezervare bilete avion 13. Sistem de management pentru o firma de curierat rapid 14. Agenda electronica 15. Sistem de management ntr-un SEL 16. Sistem pentru gestiunea cheltuielilor personale 17. Librrie online 18. Sistem de management pentru un centru medical 19. Piaa auto 20. Sistem de management a proiectelor ntr-o companie
96

Fiecare student va participa n cadrul unei echipe la realizarea unui proiect din lista temelor propuse (numarul de membri ai echipei este de 3 persoane). Raportul trebuie sa conin: 1. Foaia de titlu 2. Scopul lucrrii 3. Noiuni generale 4. Mersul lucrrii 4. Diagrama UML 5. Concluzie A2. Ghid de utilizare a instrumentului Enterprise Architect Enterprise Architect prevede modelarea complet a ciclului de via pentru: - Afaceri i sisteme IT - Software i ingineria sistemelor -Integrarea dezvoltrii n timp real Integrnd capacitile de gestionare a cerinelor, Enterprise Architect ajut la urmrirea specificaiilor la nivel nalt pentru analiza, proiectarea, implementarea, testarea i ntreinerea modelelor folosind UML. Enterprise Architect este un instrument grafic, proiectat pentru a ajuta echipele, construind sisteme robuste i ntreinute. Utiliznd calitatea nalt, integrarea raportrii i documentrii poate oferi o viziune mprtit cu uurin i precizie. Crearea unui proiect nou Cnd pornii Enterprise Architect se deschide pagina de start: 1.Facei clic pe opiunea Create a New Project. Se afieaz fereastra de dialog New Project.

97

2. n cmpul File name, tastai un nume semnificativ pentru proiect i facei clic pe butonul Save pentru a crea fiierul de proiect. Apoi se afieaz fereastra de dialog Select Model(s). 3. Selectm unul sau mai multe template-uri model, prin selectarea checkbox-ului fiecrui model care v intereseaza. 4. Facei clic pe butonul OK. Enterprise Architect creeaz un pachet de model pentru fiecare ablon selectat i l afieaz n browser-ul proiectului, pe partea dreapt a ecranului. View-ul Diagramelor este fereastra principal al spaiului de lucru, care ne permite s crem i vizualizm diagrame.

Putem deschide mai multe diagrame, dar putem vizualiza doar una la un moment dat. Diagrama se deschide prin dublu-clic pe numele diagramei n Project
98

Browser. n acelai mod putem deschide i celelalte diagrame, sau fcnd clic pe hyperlink-uri dintr-o diagram deschis, ori fcnd clic pe elementele care conin alte diagrame. Utilizai View-ul Diagramelor pentru a construi relatiile i elementele modelului. n cadrul diagramei, avem posibilitatea s crem elemente noi, s micm elemente existente i n general putem s organizm elementele i relaiile. nelegerea modului de lucru i organizare a elementelor este esenial, deoarece cel mai mult n View-ul Diagramelor se opereaz cu elementele. Utilizai exemplele furnizate de Enterprise Architect pentru a explora capacitile i comportamentul View-ul Diagramelor. Ce este Toolbox-ul. Enterprise Architect UML Toolbox este un panou de pictograme pe care le utilizm pentru a crea elemente i legturi ntr-o diagrama. n cadrul Toolbox-ului, elemente UML i tipurile de legturi sunt organizate n pagini, fiecare pagin conine elemente sau legturi utilizate pentru un anumit tip de diagram. Diagramele includ diagrame UML standard, diagrame Enterprise Arhitect extinse. Cnd deschidei genereaz o n diagrama, mod Toolbox-ul de instrumente i relaiile automat elementele

corespunztoare tipului de diagrama. Acest lucru nu ne mpiedic s utilizm alte elemente i legturi de pe alte pagini n diagram dat, dei unele asocieri s-ar putea s nu fie valide n UML. Crearea Elementelor i legturilor: 1. n Project Browser, facei dublu-clic pe iconia diagramei necesare. Diagrama se va deschide cu Toolbox-ul corespunztor tipului de diagram selectat.

99

(Dac dorii un set diferit de elemente i legturi, facei clic pe More tools i selectai tipul de diagrama corespunztoare). 2.Facei clic pe elementul necesar, de exemplu, elementul tip clas sau relaie de Associere. 3. Pentru crearea elementelor, facem clic oriunde pe diagrama pentru a plasa noul element. 4.Pentru a crearea legturi, tragem cursorul ntre elementul surs i elementul destinaie al diagramei. Pentru a schimba direcia legturii, apsai [Shift] n timp ce schimbai direcia cursorului. Alternativ, dac tragem de la elementul surs n spaiul liber al diagramei, Quick-linker-ul v permite s creai elementul destinaie. 5. Editm proprietile elementului sau proprieti legturilor, dup dorin. Project Browser-ul Project Browser-ul v permite s navigai prin spaiul proiectului Enterprise Arhitect. El afieaz pachete, diagrame, elemente i proprietile elementelor. Dac facei clic dreapta pe un element n Project Browser, avei posibilitatea s efectuai aciuni suplimentare, cum ar fi adugarea de pachete noi, crearea de diagrame, articole redenumirea, crearea de documente i de alte rapoarte, i tergerea elementelor modelului. Asemenea, putei edita numele oricorui element din Proiect Browser prin selectarea elementului i apsnd pe tasta [F2].

3 4

10

1-Creaz un Model nou n proiect, de la un model UML predefinit sau utiliznd tehnologia abloanelor 2- Creaz un pachet nou sub pachetul selectat 3 - Creaz o diagram nou sub elementul sau pachetul selectat 4 - Creaz un element nou sub elementul sau pachetul selectat
100

5 - Efectuaiaz o simpl cautare dup un text n Proiect Browser 6 - Ofer opiuni pentru a genera un raport tip RTF, HTML sau doar un raport Diagram a pachetului selectat n Proiect Browser 7 - Ofer opiuni pentru generarea codului surs sau DDL, importul directorului surs, modul binar sau schem bazei de date, genereaz coninutul pachetului pentru a fi sincronizat cu codul pachetului, sau resetarea codul surs al limbajului, toate pentru pachetul selectat 8 - Mut elementul selectat sau pachetul cu o poziie mai sus n Project Browser, n cadrul pachetului printe 9 - Mut elementul selectat sau pachetul cu o poziie mai jos n Project Browser, n cadrul pachetului printe 10- Deschide Ajutorul Enterprise Architect n browserul proiectului Browser-ul de proiect pote fi mprit n vederi (views), fiecare din aceste vederi conine diagrame, pachete i alte elemente. Mai jos este descris ierarhia unei vederi implicite, ns noi avem posibilitatea s crem diferite vederi care se potriviesc cerinelor proiectului:
Vederi (View) Use Case View Dynamic View Logical View Component View Deployment View Custom View 101

Tab-ul Diagramei este situat fie n partea de jos sau n partea de sus a zonei diagramei, deasupra barei de stare.

Locaia implicit este n partea de jos a zonei diagramei. De fiecare dat cnd deschidei o diagram, numele diagramei este afiat n tab pentru a o identifica i accesa mai uoar. Observai c tab-ul AICollections este bold, acest lucru nseamn c diagrama curent este diagrama AICollections. De asemenea, observai c diagrama Class Model are un asterisc. Acest lucru nseamn c exist modificri care nu au fost salvate n aceast diagram.

102

Ingineria programrii
ndrumar de laborator

Autor: Emilian GUULEAC

Bun de tipar 10. 05.2011 Hrtie ofset. Tipar ofset. Coli de tipar 6,50

Formatul hrtiei 60x84 1/16 Tirajul 75 ex. Comanda nr.

U.T.M. 2011, Chiinu, bd. tefan cel Mare, 168. Secia Redactare i Editare a U.T.M. 2068, Chiinu, str. Studenilor, 11.

103