UNIVERSITAREA POLITEHNICA BUCURESTI Facultatea Electronica, Telecomunicatii si Tehnologia Informatiei

Referat Inginerie Software

UML

Berevoianu Adelina Epure Adriana Tinta Mihaita Grupa 443 A

2011

Cuprins
1. Introducere 2. Strategii de formalizare 2.1 Arhitectura UML 2.2 Modele 3. Modelarea cu UML 3.1 View-uri 3.2 Diagrame 3.2.1 Diagrame structurale 3.2.1.1 Diagrama claselor (Class Diagram) 3.2.1.2 Diagrama obiectelor (Object Diagram) 3.2.1.3 Diagrama componentelor (Component Diagram) 3.2.1.4 Diagrama de desfurare (Deployment View) 3.2.2 Diagrame comportamentale 3.2.2.1 Diagrama cazurilor de utilizare (Use Case Diagram) 3.2.2.2 Diagrama de activitate (Activity Diagram) 3.2.2.3 Diagrama de stare (State Diagram) 3.2.2.4 Diagrama de interactiune (Interaction Diagram) 3.2.2.4.1 Diagrama de Secventa (Sequence Diagram) 3.2.2.4.2 Diagrama de Colaborare ( Collaboration Diagram) 4. Concluzii 5. Bibliografie

Introducere
UML (Unified Modelling Language) reprezinta un limbaj vizual de modelare folositor n domeniul software, dedicat construirii sistemelor complexe si realizarii documentelor de specificaii, facand referire in mare parte la vizualizarea, specificarea, construirea i documentarea sistemelor de aplicaii. Prezinta si limitri cu privire la generarea codului i reprezinta de asemenea un mijloc bun pentru domeniul ingineriei programrii. Scopul unui limbaj de modelare este analiza si proiectarea programelor. UML reprezinta limbajul universal standard pentru dezvoltatorii software de pretutindeni, si de asemenea o combinatie excelenta a celor mai bune trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT, and OOSE). Asadar limbajul UML reunete cele mai bune tehnici i practici din domeniul ingineriei programrii, care i-au dovedit eficiena n construirea sistemelor complexe, rezultatul avand o expresivitate foarte buna care ajuta la rezolvarea diverselor probleme de modelare pe care vechile limbaje nu reuseau sa le indeplineasca foarte bine. UML ar putea indeplini pe langa rolul de limbaj vizual de modelare si cel de limbaj vizual de programare, dar momentan nu dispune de ntreg sprijinul semantic i vizual pentru a nlocui limbajele de programare Limbajul de modelare modificat (UML - The Unified Modeling Language) consta in arhitecturi de sisteme ce functioneaza pe analiza si proiectarea obiectelor cu un limbaj corespunzator pentru specificarea, vizualizarea, construirea si documentarea artefactelor sistemelor software si de asemenea pentru modelarea n ntreprinderi. UML este un limbaj de modelare care ofera o exprimare grafica a structurii si comportamentului software. Pentru aceasta exprimare grafica se utilizeaza notatiile UML. UML este un limbaj de modelare vizual, orientat obiect, care descrie proprietile structurale i dinamice ale unui sistem software. Prin sistem software se ntelege o BD sau un modul de cod n general. Spre deosebire de modelul EAE, UML este o colecie de tehnici de modelare, folosite pentru tratarea multor aspecte ale procesului de concepere i dezvoltare a software-ului, de la proiectarea BD la interaciunea modulelor de cod. Fiecare tehnic de modelare de mai sus d o vedere diferit, static sau dinamic, a unei aplicaii. Colecia de vederi se numete model. Iat unele din tehnicile de modelare UML: diagrame de clase, sau diagrame statice de structur, care modeleaz entitile unui sistem prin clase cu atribute i comportare. Diagramele de clas descriu, de asemenea, asocierile dintre clase i constrngerile asupra acestora. Apoi, alte tehnici: diagrame de obiecte, diagrame de "caz de utilizare", diagrame de stare, diagrame de secvene, diagrame de activitate, diagrame de colaborare. Notatiile UML constituie un element esential al limbajului pentru realizarea propriu-zisa a modelarii si anume partea reprezentarii grafice pe care se bazeaza orice limbaj de modelare. Modelarea n acest limbaj se realizeaza prin combinarea notatiilor 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 constructie, diagrama de obiecte, diagrama de activitati. n cele ce urmeaza vor fi prezentate notatiile UML care vor fi grupate dupa diagramele corespunzatoare fiecarei notatii n parte. Adoptarea specificaiei UML ca limbaj standard de modelare a fost semnalat la 17 noiembrie 1997. n ingineria mecanic pentru a realiza modelul complet al unei piese, inginerul folosete desenul tehnic ca limbaj pentru comunicare, iar ca mod de reprezentare, vederea n epur. Aceast vedere n epur nseamn vizualizarea unei piese din trei puncte (din fa, de sus i din lateral) astfel nct piesa s fie definit complet. Un cititor avizat al desenului n epur va ti ntotdeauna s refac mental piesa desenat.

Dac din cauza complexitii piesei, cele trei fotografii nu sunt suficiente, inginerul va desena i alte detalii, sau seciuni ale piesei, dar privite din aceleai trei unghiuri. Fiecare dintre cele trei puncte de vizualizare a piesei (noi le vom zice, view-uri) reprezint un submodel capabil s descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare view arat piesa vzut dintr-un anumit punct de vedere iar modelul complet utilizeaz toate punctele de vedere relevante.

Aa cum inginerul proiectant comunic prin desen tehnic, echipei, sau oricrei alte persoane interesate ntr-un limbai standard, vizual (adic desenul tehnic), fcut s permit descrierea complet dar, in acelai timp, scutit de detalii inutile, inginerii software pot comunica cu maxim eficient Tn limbajul UML. La fel ca oricare limbai acesta trebuie nvat i exersat astfel nct fiecare cuvnt s fie neles, s tim unde i cum se folosete, astfel nct s ne putem exprima n fraze coerente, care s spun" exact ceea ce vrem s comunicm. Limbajul UML ne permite realizarea mai multor figuri, ca nite fotografii din diverse unghiuri, ale unei realiti, astfel nct aceast realitate s fie surprins prin toate aspectele ei relevante. In software vom utiliza dou puncte de vedere necesare unei descrieri suficiente a realitii: (1) structural i (2) comportamental. n standardul UML sunt definite urmtoarele diagrame, pe cele dou categorii: a. pentru descrierea structural: - Class Diagram; - Object Diagram; - Component Diagram; - Deployment Diagram. b. pentru descrierea comportamental: - Use Case Diagram; - Activity Diagram; - Statechart Diagram; - Sequence Diagram; - Collaboration Diagram.

2. Strategii de formalizare
2.1 Arhitectura UML
Pentru a ntelege arhitectura UML luam in considerare modul n care programele si limbajele de programare sunt relationate ntre ele. Exista multe limbaje de programare, iar fiecare program in parte este dezvoltat utiliznd un limbaj de programare specific. Toate aceste limbaje vor sustine diferite constructii declarative pentru a declara datele si aspectele procedurale, precum si definirea logicilor care manipuleaza datele. Deoarece modelul reprezinta o abstractizare, fiecare dintre aceste concepte luat in parte poate fi captat ntr-o multime de modele relationate. Conceptele limbajelor de programare sunt, la rndul lor definite n metamodel. Fiecare limbaj de programare este definit printr-un model care utilizeaza si specializeaza conceptele din interiorul metamodelului. Fiecare program implementat ntr-un limbaj de proiectare poate fi definit ntr-un model care se va numi model utilizator care utilizeaza si instantiaza conceptele modelului printr-un limbaj convenabil. Aceasta schema a metamodelului, de reprezentare a constructorilor de programare, modele care sa reprezinte, la rndul lor limbaje de programare si modele utilizator care sa reprezinte programe, exemplifica arhitectura UML. UML este definit n cadrul conceptual al modelarii care consta din urmatoarele patru nivele distincte de abstractizare: Nivelul meta-metamodelului, consta din elementele fundamentale pe care se bazeaza UML -conceptul de 'thing', care reprezinta orice ce poate fi definit. Acest nivel de abstractizare formalizeaza notiunea unui concept si defineste un limbaj pentru specificarea metamodelului. Nivelul metamodelului - consta din acele elemente care constituie UML, incluznd concepte din paradigmele orientate obiect si orientate componente. Fiecare concept al nivelului este o instanta (prin intermediul stereotipurilor) a conceptului meta-metamodelului 'Thig' Acest nivel de abstractizare este utilizat pentru formalizarea conceptelor paradigmei si la definirea unui limbaj pentru specificarea modelelor Nivelul model - consta din modele UML. Acesta este nivelul la care se produce: modelarea problemelor, solutia sau sistemul. Fiecare concept din acest nivel este o instanta (prin intermediul stereotipurilor) a unui concept din nivelul metamodelului. Acest nivel de abstractizare este utilizat la formalizarea conceptelor si la definirea limbajului pentru comunicarea expresiilor cu privire la un subiect dat. Modelele de pe acest nivel mai sunt numite clase sau modele ale tipurilor. Nivelul model utilizator - consta din acele elemente care exemplifica modelele UML. Fiecare concept din acest nivel este o instanta (prin intermediul clasificarii) a conceptelor din nivelul model si o instanta (prin stereotipuri) a unui concept din nivelul metamodel. Acest nivel de abstractizare este utilizat pentru a formaliza expresiile specifice cu privire la un subiect dat. Modelele din acest nivel sunt numite si obiecte sau instante ale modelului

2.2 Modele
Modelele capteaza caracteristicile structurale sau statice ale sistemelor si comportamentul, sau caracteristicile dinamice ale acestuia. Modelele pot fi privite ca prin intermediul unei multimi de dimensiuni (aspecte) independente care etaleaza calitati particulare ale modelului. Fundamental, modelele capteaza cunostinte (semantici). Perspectiva arhitecturala Perspectiva arhitecturala organizeaza modelele si cunostintele n jurul unei multimi specifice de interese (focusarea arhitecturala). UML da urmatoarele perspective arhitecturale cu privire la modele sau probleme si solutii: modelul utilizator - contine o problema si o solutie ca ntelese de elementele individuale carora li se adreseaza respectiva problema (solutie). Aceasta perspectiva este de asemenea numita use case sau scenariu; modelul structural - cuprinde dimensiunea structurala a unei probleme si solutii. Aceasta perspectiva este cunoscuta ca fiind perspectiva statica sau logica; modelul comportamental - cuprinde dimensiunea comportamentala a problemei si solutiei. Aceasta perspectiva este cunoscuta de asemenea ca fiind: dinamica, de proces, concurenta sau colaborativa; modelul implementarii cuprinde dimensiunea comportamentala si structurala a realizarii solutiilor, fiind cunoscuta si ca: de dezvoltare sau de componente; modelul de mediu - cuprind dimensiunea structurala si comportamentala a domeniului n care este realizata solutia. Este cunoscuta si ca perspectiva fizica; Se pot defini si alte perspective, n cazul n care este remarcata necesitatea acestora. O orientare arhitecturala este definita printr-o multime de continuturi. O perspectiva arhitecturala este definita prin intermediul unei multimi de elemente dintr -un model care refera o orientare arhitecturala. De exemplu, securitatea poate fi definita ca o orientare arhitecturala. O arhitecturalitate a securitatii va include multime a elementelor modelului care adreseaza securitatea. Fundamental, perspectiva arhitecturala organizeaza cunostintele n concordanta cu ghidurile date de exprimarea idiomurilor necesare utilizarii. Diagrame Diagramele prezinta cunostinte ntr-o forma comunicabila. UML furnizeaza urmatoarele diagrame, organizate n jurul perspectivei arhitecturale cu privire la modelele problemelor si a solutiilor: e perspectiva modelului utilizator - diagrame de scenarii care descriu functionalitatea sistemului e perspectiva modelului structural - clasa de diagrame care descriu structura statica a sistemului diagrame obiect care descriu structura statica a sistemului la un moment particular de timp. e perspectiva comportamentala - diagrame de secvente care descriu o interactiune de-a lungul elementelor sistemului organizat n secventa temporale - diagrame de colaborare care descriu o interactiune de-a lungul elementelor unui sistem si a relatiilor acestora, organizate n timp si spatiu - diagrame de stare care descriu conditiile de stare si raspunsurile elementelor sistemului - diagrame de activitate care descriu activitatea elementelor sistemului. e perspectiva modelului implementare - diagramele de componente care descriu organizarea elementelor care realizeaza sistemul e perspectiva modelului de mediu - diagrame de desfasurare care descriu configuratia elementelor de mediu si maparea elementelor care realizeaza sistemul peste acestea e alte diagrame pot fi definite si utilizate dupa necesitati. Mecanismele de modelare Mecanismele sunt practici pentru abordarea modelarii si a realizarii diagramelor care -

valideaza creare de modele din ce n ce mai precise si ceea ce este mai important, din ce n ce mai comunicabile. Perspectivele definesc un punct de vedere particular de la care se pot elabora sau citi diagrame. Acestea valideaza asocierea de puncte de vedere clare cu diagrame si sunt utilizate pentru eficientizarea comunicarilor; Dihotomiile definesc modul n care ceva poate fi privit din doua perspective diferite. Acestea valideaza o privire asupra unei entitati din puncte de vedere multiple si sunt utilizate (fiind foarte eficiente n acest scop) la depistarea inconsistentelor dintre modele; Nivelele de abstractizare definesc un nivel particular si stabilesc nivelul de detaliu cu privire la un subiect (problema sau solutie). Acestea permit orientarea spre comunicare si sunt utilizate pentru organizarea tuturor diagramelor care apartin unui singur model ntr-un singur corp de cunostinte, coerent; Extensia mecanismelor defineste mijlocul prin care se poate realiza personalizarea si extinderea UML. Aceasta permite UML sa fie flexibil si adaptiv si este utilizat pentru a asigura UML evolueaza, solutie mai buna dect redefinirea necesara pentru descrierea nevoilor de modificare sau a cerintelor. ntr-un proces problema - solutie, cunostintele cu privire la o problema si o solutie sunt captate, organizate n jurul deciziei si descrise utiliznd UML astfel nct pot fi comunicabile si plasate pe diferite nivele.

3. Modelarea cu UML
Conceptele folosite n cadrul diagramelor UML se numesc elemente de modelare. Un element de modelare are o semantic, o definiie formal a elementului sau un neles exact a ceea ce reprezint el ntr-un anumit context, i o reprezentare grafic, sau un simbol grafic cu care se reprezint n cadrul diagramelor. Un element poate fi regsit n mai multe tipuri de diagrame i pentru fiecare context exist propriile reguli. n figura 1 sunt prezentate cteva exemple de elemente de modelare mpreun cu modul lor de reprezentare. A modela cu UML nseamn a construi mai multe modele pentru diferitele faze ale dezvoltrii i pentru diverse scopuri. Exist mai multe faze ce trebuie parcurse: faza de analiz - surprinde necesitile sistemului i modeleaz clasele de baz din "lumea real" i colaborrile dintre acestea; faza de design - se detaliaz modelul din faza de analiz i se formuleaz o soluie tehnic lund n considerare caracteristicile mediului n care acesta va fi reprezentat; faza de implementare - modelul este transpus n cod iar apoi compilat n programe; modelul de desfurare - se folosete o descriere care explic modul cum va fi adaptat sistemul arhitecturii fizice concrete.

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. Diagram asociat: diagram de cazuri de utilizare 0 Modelul structural: se realizeaz pe baza analizei statice a problemei i descrie

proprietile statice ale entitilor care compun domeniul problemei. Diagrame asociate: diagram de module, diagram de clase 1 Modelul comportamental: privete descrierea funcionalitiilor i a succesiunii n timp a aciunilor realizate de entitile domeniului problemei. Diagrame asociate: diagrama (harta) de stri, diagrama de colaborare, diagrama de interaciune Principalele pri ale UML sunt: 0 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. 1 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. 2 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

3.1 View-uri
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 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 o proiecie a descrierii intregului sistem i care reflect un anumuit aspect al sau. Fiecare view este descris folosind un numr de diagrame care conin informaii relative la un anumit aspect particular al sistemului. Aceste view-uri se acoper unele pe altele, deci este posibil ca o anumit diagram s fac parte din mai multe view-uri.

Figura 1: View-urile din UML VIEW-UL CAZURILOR DE UTILIZARE (USE-CASE VIEW) - Acest view surprinde funcionalitatea sistemului, aa cum este ea perceput de actorii externi care interacioneaz cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. n componena lui intr diagrame ale cazurilor de utilizare i ocazional, diagrame de activitate. Cei interesai de acest view sunt deopotriv clienii, designerii, dezvoltatorii dar i cei care vor realiza testarea i validarea sistemului.

VIEW-UL LOGIC (LOGIC VIEW) - Spre deosebire de view-ul cazurilor de utilizare, un view logic "privete" nuntrul sistemului i descrie att structura intern a acestuia (clase, obiecte i relaii) ct i colaborrile care apar cnd obiectele trimit unul altuia mesaje pentru a realiza funcionalitatea dorit. Structura static este descris n diagrame de clas, n timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secvent, de colaborare sau de activitate. Prin urmare, cei care sunt interesai de acest tip de vizualizare a sistemului sunt designerii i dezvoltatorii. VIEW-UL COMPONENTELOR (COMPONENT VIEW) - Componentele sunt module de cod de diferite tipuri. n funcie de coninutul lor acestea pot fi: componente care conin cod surs, componente binare sau excutabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem i dependenele ce exist ntre ele, precum i resursele alocate acestora i eventual alte informaii administrative, cum ar fi de exemplu un desfaurtor al muncii de dezvoltare. Este folosit n special de dezvoltatorii sistemului, iar n componena sa intr diagrame ale componentelor. VIEW-UL DE CONCUREN (CONCURENT VIEW) - Sistemul poate fi construit astfel nct s ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncional, este util pentru o gestionare eficient a resurselor, execuii paralele i tratri asincrone ale unor evenimente din sistem, precum i pentru rezolvarea unor probleme legate de comunicarea i sincronizarea theadu-urilor. Cei care sunt interesai de o astfel de vizualizare a sistemului sunt dezvoltatorii i integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secvent, colaborare i activitate) i diagrame de implementare (ale componentelor sau de desfurare).
VIEW-UL DE DESFURARE (DEPLOYMENT VIEW) - Desfurarea fizic a sistemului, ce calculatoare i ce device-uri (numite i noduri) vor fi folosite pentru realizarea efectiv a implementrii, cum sunt acestea conectate, precum i ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse n view-ul de desfurare. Aceast tip de vizualizare a sistemului prezint interes sunt dezvoltatori, integratorii de sistem i cei care realizeaz testarea sistemului, iar pentru construirea view-ului este folosit diagrama de desfurare.

3.2 Diagrame
n UML sunt nou tipuri de diagrame, care vor fi prezentate pe larg n cele ce urmeaz.

Diagramele UML pot fi mprite n: diagrame pentru modelarea structurii statice i diagrame pentru modelarea comportamentului. 1. Diagramele structurale sunt folosite pentru a vizualiza, specifica, construi i documenta aspectele statice ale sistemului. Acestea sunt organizate n jurul grupelor majore de elemente ce pot fi gsite n modelarea unui sistem. Din aceast categorie fac parte: Diagrama claselor (Class Diagram) - prezint structura fizic a claselor identificate n sistem. Clasele reprezint "lucruri" gestionate de sistem. Este cel mai utilizat tip de diagrame n modelarea sistemelor orientate obiect. Diagrama componentelor (Component Diagram) - prezint structura fizic a codului n termenii componentelor de cod. Se folosete pentru a ilustra vederea static de implementare a unui sistem. Diagrama obiectelor (Object Diagram) - este o variant a diagramei claselor care, n locul unei clase, prezint mai multe instane ale ei. Diagrama de stare (State Diagram) - prezint toate strile prin care trece un obiect al clasei, precum i evenimentele care-i cauzeaz modificrile de stare. 3. Diagramele comportamentale sunt folosite pentru a vizualiza, specifica, construi i documenta aspectele dinamice ale unui sistem. Acestea sunt organizate n jurul modalitilor principale de a modela dinamica unui sistem. Din aceast categorie fac parte: Diagrama cazurilor de utilizare (Use Case Diagram) - prezint actorii externi i cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, aa cum este el perceput de utilizatorii lui ?) nu i din interior, precum i conexiunile identificate ntre actori i cazurile de utilizare. Diagrama de secven (Sequence Diagram) - prezint colaborarea dinamic ntre un numr de obiecte, mai precis, secvenele de mesaje trimise ntre acestea, pe msura scurgerii timpului. Diagrama de colaborare (Collaboration Diagram) - surprinde colaborarea dinamic ntre obiecte, ntr-o manier similar cu a diagramei de secven, dar pe lng schimbul de mesaje (numit i interaciune) prezint obiectele i relaiile dintre ele (cteodat referite ca i context). Diagrama de activitate (Activity Diagram) - prezint fluxul secvenelor de activiti i este de obicei folosit pentru a descrie activitile realizate n cadrul unei operaii, folosind dac este cazul decizii i condiii. Diagrama de tranziie - se folosete pentru a ilustra vederea dinamic a unui sistem. Cum lum decizia folosirii unui anumit tip de diagram ? Dac cel mai important aspect este timpul sau secvena de mesaje vom folosi diagrama de secven, dar dac trebuie scos n eviden contextul, vom apela la o diagram de colaborare. Mesajele vor fi reprezentate prin sgei ntre obiectele implicate n mesaj i pot fi nsoite de etichete care specific ordinea n care acestea vor fi transmise. De asemenea, se pot vizualiza condiii, iteraii, valori returnate, precum i obiectele active care se execut concurent cu alte obiecte active. Diagramele sunt grafuri care prezint simboluri ale elementelor de modelare (model element) aranjate astfel nct s ilustreze o anumit parte sau un anumit aspect al sistemului. Un model are de obicei mai multe diagrame de acelai tip. O diagram este o parte a unui view specific, dar exist posibilitatea ca o diagram s fac parte din mai multe view-uri, n funcie de coninutul ei. n UML sunt nou tipuri de diagrame pe care le vom prezenta n cele ce

urmeaz.

3.2.1 Diagrame structurale

3.2.1.1 Diagrama claselor (Class Diagram)
O diagram a claselor prezint structura fizic a claselor identificate n sistem. Clasele reprezint "lucruri" gestionate de sistem; clasele pot fi legate n mai multe moduri: asociate (conectate ntre ele), dependente (o clasa depinde/folosete o alt clas), specializate (o clas este specializarea altei clase) sau mpachetate (grupate mpreun n cadrul unei unitai). Toate aceste relaii se materializeaz n structura intern a claselor n atribute i operaii. Diagrama este considerata statica, in sensul ca este valida in orice moment din ciclul de viata al sistemului. Class diagram este un tip de diagram utilizat pentru descrierea structurii statice, adic a entitilor sau claselor existente ntr-un sistem. Acest tip de diagram este utilizat cel mai adesea de ctre dezvoltatori pentru specificarea claselor dar poate fi foarte util i pentru specificarea structurii unor sisteme sau subsistem dintr-un business real. Diagrama de clase nu este utilizata doar pentru vizualizarea, descrierea i documentarea diferitelor aspecte ale unui sistem, ci, de asemenea, pentru construirea codului executabil al aplicaiei software. Ea descrie atributele i operaiunile unei clase i, de asemenea, constrngerile impuse asupra sistemului. Schemele de clasa sunt utilizate pe scar larg n modelarea sistemelor orientate obiect, deoarece acestea sunt diagrame UML singurul care poate fi mapate direct cu limbaje orientate obiect. Diagrama de clase prezinta o colectie de clase, interfee, asociaii, colaborri i constrngeri. De asemenea, este cunoscuta ca o diagram structural.

Scop:
Scopul diagramei de clase este de a modela opinia statica a unei aplicatii. Diagramele de clas sunt singurele diagrame care poate fi mapate direct cu limbaje orientate pe obiect i, astfel, utilizate pe scar larg n momentul de construcie. Diagramele UML ca diagrama de activitate, diagrama de secven pot da doar fluxul de ordine al aplicatiei, dar diagrama de clase este un pic diferita. Deci, aceasta este cea mai populara diagrama UML n comunitatea programatorilor. Deci, scopul diagramei de clase pot fi rezumate astfel:

Analiza i proiectarea reprezentarii statice a unei cereri. Descriei responsabilitile unui sistem. Componenta de baz pentru diagramele de implementare si componente. Compilare si inversa.

Cum se deseneaza diagrama de clase?

Diagramele de clase sunt cele mai populare diagramele UML utilizate pentru construirea de aplicatii software. Deci, este foarte important a afla procedura de desenare a diagramei de clase. Diagramele de clase au mulime de proprieti care se iau n considerare n timpul reproducerii schemei, dar aici diagrama va fi considerata dintr-o perspectiv la nivel de top. Diagrama de clase este de fapt o reprezentare grafic a vederii statice a sistemului i reprezint aspecte diferite ale aplicatiei. Deci, o colectie de diagrame de clase reprezint ntregul sistem. Ar trebuii sa se tina cont de urmtoarele puncte n timp ce desenai o diagrama de clase:

Numele diagramei de clase ar trebui s fie semnificativ pentru a descrie aspectul sistemului. Fiecare element i relaiile lor ar trebui s fie identificate n prealabil. Responsabilitatea (atribute i metode) ale fiecarei clase ar trebui s fie identificate n mod clar. Pentru fiecare clasa ar trebuii specificat numrul minim de proprieti. Deoarece proprietile inutile vor face diagrama de complicat. Utilizai note oricand este necesar pentru a descrie unele aspecte ale diagramei. Deoarece la sfritul reprezentarii ar trebui s fie neles de ctre dezvoltator / programator. n cele din urm, nainte de a face versiunea final, diagrama ar trebui s fie elaborata pe o simpla hrtie i revizuita de cte ori este posibil pentru a o face corect.

Acum diagrama de mai jos este un exemplu de un Sistem Ordonat al unei aplicatii. Deci, aceasta descrie un anumit aspect al intregii aplicatii.

Mai nti de toate, Order i a Customer sunt identificati ca fiind cele dou elemente ale sistemului i au o relaie unu la mai multe, deoarece un client poate avea mai multe comenzi. Clasa Order este o clas abstract i are dou clase (relaia motenire) i SpecialOrder si NormalOrder. Cele dou clase au motenit toate proprietatile ca si clasa Order. n plus, acestea au funcii suplimentare, cum ar expediere () i s primeasc ().

Astfel, urmatoarea diagrama de clase a fost elaborata lund n considerare toate punctele menionate mai sus:

Unde se utilizeaza diagramele de clase?

Diagrama de clase este o diagrama statica i este folosit pentru a vizualiza modelul static al unui sistem. Punctul de vedere static descrie vocabularul sistemului. Diagrama de clase este, de asemenea, considerata ca fundament pentru diagramele de componente si de implementare. Diagramele de clase nu sunt folosite doar pentru a vizualiza reprezentarea static a sistemului, dar acestea sunt, de asemenea, utilizate pentru a construi codul executabil pentru compilare si inversa al oricarui sistem. n general, diagramele UML nu sunt direct cartografiate cu orice limbaje de programare orientate pe obiect, dar diagrama de clase este o excepie. Diagrama de clase arat n mod clar maparea cu limbaje orientate obiect cum ar fi Java, C + +, etc. Deci, din experiena practic diagrama de clase este, n general, utilizata n scopul construirii. Deci, mai pe scurt, diagramele de clase sunt utilizate pentru:

Descrierea reprezentarii statice a sistemului. Arata colaborarea dintre elementele de tip static. Descrie funcionalitile efectuate de ctre sistem. Construirea de aplicatii software folosind limbaje orientate pe obiect.

Elementele utilizate i notaiile lor sunt urmtoarele: Element Descriere Notaie

Clas

O clas este reprezentat printr-un dreptunghi cu trei compartimente: n cel de sus se trece numele clasei, n mijloc se trec atributele clasei iar jos se trec operaiile specifice clasei. Motenirea este o relaie care indic faptul c o clas motenete caracteristicile unei clase printe. Sensul sgeii indic sensul n care se poate spune despre clasa copil c este o<-i>, sau este de tipul<-i> clas printe. Asocierea este o relaie generic ntre dou clase. Aceste relaii pot fi de tipurile pot defini i regulile numerice de asociere (unu la unu, unu la mai muli, mai muli la mai muli).

Motenire

Asociere

Atunci cnd o clas depinde de o alt clas, n sensul c Dependen utilizeaz acea clas ca i atribut al su, se folosete relaia de dependen. Agregarea indic o relaie de tip ntreg-parte (se poate spune despre clasa printe c are clase de tip copil). n aceast relaie, clasa copil poate exista i fr clasa printe.

Agregare

Aceast relaie deriv din agregare dar se utilizeaz atunci Compoziie cnd o clas copil nu poate exista dect n cazul existenei clasei printe. n reprezentarea clasei atributele i operaiile sunt declarate n compartimentele speciale din dreptunghi, astfel: - atributele:
numele atributului : tipul atributului = valoare implicit

- operaiile:
numele operaiei (parametri) : tipul valorii returnate

Atunci cnd diagrama este folosit pentru a modela structuri de business se pot folosi tipurile de date specifice business-ului, nu programrii, de exemplu: minut, dat calendaristic, minut etc.

Motenirea este o relaie prin care se indic faptul c o clas motenete caracteristicile clasei printe. n plus, clasa copil poate avea propriile caracteristici.

Asocierea arat existena unei relaii ntre clase. n exemplul de mai jos, ntre Persoan i Autovehicul urmtoarea relaie: o Persoan poate avea zero, unul sau mai multe Autovehicule.

Un tip special de asociere este indicat printr-o clas de asociere. Altfel spus, relaia n sine este o clas. n exemplul de mai jos, relaia dintre Articol i Lista de preuri este de tip mai muli la mai muli: un Articol poate s apar pe mai multe Liste i o List poate avea mai multe Articole. Pe Liste diferite Articolele pot avea preuri diferite.

Dependena indic faptul c o clas depinde de alt clas, n sensul n care o funcie oarecare depinde de un parametru al su.

Agregarea indic faptul c o clas printe are elemente de tipul clasei copil. n exemplul de mai jos.ara poate avea mai multe Judee dar, n acelai timp, un Jude poate exista chiar i n cazul

n care clasa ara nu exist.

ntr-o relaie de tip compoziie clasa copil nu poate exista dect dac exist o instan a clasei printe. n exemplul de mai jos instana clasei Comisie exist atta timp ct exist instana clasei Examen.

Figura 3: O diagram a claselor pentru un sistem de asigurri.

3.2.1.2 Diagrama obiectelor (Object Diagram)

Acest tip de diagram este un variant al diagramei claselor care n locul unei clase prezint mai multe instane ale ei. Diagrama obiectelor folosete aproape aceleai notaii ca i diagrama claselor cu dou mici diferene: obiectele sunt scrise subliniat i sunt vizualizate toate instantele relaiei (figura 4). Dei nu este la fel de important ca diagrama claselor, cea o obiectelor este folosit pentru exemplificarea unei diagrame a claselor de complexitate mare, permind vizualizari ale instanelor actuale i a relaiilor exact aa cum sunt ele realizate. Mai poate fi folosit ca o parte a diagramelor de colaborare, n care sunt vizualizate colaborrile dinamice existente n cadrul unui set de obiecte. Diagramele obiect sunt derivate din diagramele de clase, astfel diagrame de obiecte sunt dependente de diagrame de clase; reprezinta o instanta a unei diagrame de clase. Conceptele de baz sunt similare pentru diagramele de clase i diagramele obiect. Diagrame obiect reprezint, de asemenea, punctul de vedere static al unui sistem, dar acest punct de vedere static este un instantaneu al sistemului la un moment dat. Diagramele obiect sunt utilizate pentru a face un set de obiecte i relaiile lor ca o instan.

Scop:
Scopul unei diagrame ar trebui s fie neles n mod clar pentru a putea fi pus n aplicare practic. Scopul diagramelor de obiect este similar cu cel al diagramelor de clase. Diferenta este ca o diagrama de clase reprezint un model abstract format din clase i relaiile lor. Dar un obiect diagram reprezint o instan la un moment dat, care este concret n natur. Aceasta nseamn c diagrama obiect este mai aproape de comportamentul sistemului actual. Scopul este de a captura vederea statica a unui sistem la un anumit moment. Deci, scopurile diagramei obiect pot fi rezumate astfel:

Compilare si inversa. Relaiile obiectului unui sistem Vedere statica a unei interaciuni. nelegerea comportamentului obiect i relaia lor din punct de vedere practic

Cum se deseneaza diagrama obiect?

Am discutat deja c o diagrama obiect este o instanta a unei diagrama de clase. Aceasta implic faptul c un obiect diagram este format din instane de lucruri utilizate ntr-o diagrama de clase. Deci, ambele diagrame sunt facute din aceleasi elemente de baz, dar n diferite forme. n diagrama de clase sunt elemente ntr-o form abstract pentru a reprezenta imprimare albastru i n diagrama obiect elementele sunt ntr-o form concret pentru a reprezenta obiectul in lumea real. Pentru a captura un anumit sistem, numrul de diagrame de clase sunt limitate. Dar, dac lum n considerare diagramele obiect, atunci putem avea un numr nelimitat de instane, care sunt unice n natur. Deci, sunt luate n considerare numai acele cazuri care au un impact asupra sistemului. Din discuia de mai sus este evident c o singura diagrama obiect nu poate capta toate instanele necesare sau, mai degrab nu poate specifica toate obiectele dintr-un sistem. Deci, soluia este:

n primul rnd, o analiz a sistemului i s se decid care sunt instanele care au date importante i de asociere. n al doilea rnd, se ia n considerare numai acele cazuri care vor acoperi funcionalitatea. n al treilea rnd, se fac unele optimizari avand in vedere ca numrul de instane sunt nelimitate.

nainte de a se desena diagramele unui obiect, trebuie tinut seama de urmtoarele lucruri :

Diagramele obiect sunt formate din obiecte. Legatura din diagrama de obiect este folosita pentru a conecta obiecte. Obiectele i link-urile sunt dou elemente folosite pentru a construi o diagram obiect.

Acum, dup aceasta, trebuie tinuta seama de urmatoarele lucruri care urmeaz s fie stabilite nainte de a ncepe construcia diagramei:

Diagrama de obiect ar trebui s aib un nume semnificativ pentru a indica scopul su. Cele mai importante elemente trebuie s fie identificate. Asocierea dintre obiecte ar trebui s fie clarificata.

Valorile unor elemente diferite ar trebui s fie capturate si apoi incluse n diagrama de obiect. Adugarea de note corespunztoare n punctele n care este necesar mai mult claritate.

Diagrama de mai jos este un exemplu de o diagram obiect. Ea reprezint sistemul de management al comenzii pe care le-am discutat n diagrama de clase. Diagrama de mai jos este o instanta a sistemului la un anumit moment de cumprare. Acesta are urmtoarele obiecte

Customer Order SpecialOrder NormalOrder

Acum obiectul Customer (C) este asociat cu trei obiecte de ordine (O1, O2 i O3). Aceste obiecte de ordine sunt asociate cu ordine speciale i obiecte normale de comand (S1, S2 i N1). Customer are urmtoarele trei ordine cu numere diferite (12, 32 i 40) pentru anumite perioade luate n considerare. Acum clientul poate creste numarul de Order, n viitor, i n acest scenariu diagrama obiect va reflecta acest lucru. Dac Order, SpecialOrder i NormalOrder sunt observate, atunci vom gsi c acestea au anumite valori. Pentru Orders valorile sunt 12, 32, i 40 ceea ce implic faptul c obiectele sunt cu aceste valori pentru un moment anume (aici, momentul particular de timp n cazul n care achiziia se face este considerat ca fiind momentul), atunci cnd instana este capturata. Acelai lucru este si pentru SpecialOrder i NormalOrder, care au numarul de Orders ca 20, 30 i 60. n cazul n care un alt moment de cumprare este considerat, atunci aceste valori se vor schimba n consecin. Asadar, urmatoarea diagrama a fost elaborat lund n considerare toate punctele menionate mai sus:

Unde folosim diagramele obiect?

Diagramele obiect pot fi imaginate ca o imagine dintr-un sistem care ruleaz la un moment dat. Acum, pentru a se clarifica putem lua un exemplu de un tren in miscare.

Acum, dac luati un anumit moment din circulaia trenului, vei gsi o imagine static a acesteia avnd urmtoarele:

O situatie speciala, care se execut Un anumit numr de pasageri. care se va schimba n cazul n care momentul este luat la un alt moment de timp.

Deci, aici ne putem imagina ca momentul de circulaie al trenului este un obiect avnd valorile de mai sus. i acest lucru este valabil pentru orice sistem de viaa real simplu sau complex. Mai pe scurt diagramele obiect sunt utilizate pentru:

Producerea prototipului unui sistem. Decompilarea. Modelarea structurilor complexe de date. nelegerea sistemului din punct de vedere practic.

Figura 4: O diagram a claselor i o diagram a obiectelor (instanele claselor).

3.2.1.3 Diagrama componentelor (Component Diagram)

O diagram a componentelor prezint structura fizic a codului n termenii componentelor de cod, realiznd o mapare de la view-ul logic la view-ul componentelor. O component poate s conin un cod surs sau poate s fie ntr-o forma binar sau executabil. n cadrul diagramei vor fi ilustrate i dependenele dintre componente, ceea ce permite o vizualizare simpl a componentelor care vor fi afectate de modificarea uneia dintre ele.

Diagrama componentelor este diferita n ceea ce privete natura i comportamentul, si este folosita pentru a modela aspectele fizice ale unui sistem. Acum ntrebarea este care sunt aceste aspecte fizice? Aspecte fizice sunt elemente cum ar fi executabile, biblioteci, fiiere, documente, etc care i are reedina ntr-un nod. Deci, diagramele componente sunt folosite pentru a vizualiza organizarea i relaiile dintre componente ntr-un sistem. Aceste diagrame sunt, de asemenea, folosite pentru a face crea sisteme executabile.

Scop:
Diagrama Componentelor este un tip special de diagrama n UML. Scopul este, de asemenea, diferit de toate celelalte diagrame discutate pn acum. Ea nu descrie funcionalitatea sistemului, dar descrie componentele utilizate pentru a face aceste funcionaliti. Deci, din acest punct de vedere diagrama componentelor este folosita pentru a vizualiza componentele fizice ntr-un sistem. Aceste componente sunt biblioteci, pachete, fisiere, etc Diagrama component poate fi, de asemenea, descrisa ca o vizualizare a unei implementari statice al unui sistem. Implementarea statica reprezinta organizarea de componente la un anumit moment. O singura diagram a componentelor nu poate reprezenta ntregul sistem, de aceea se foloseste o colecie de diagrame pentru a reprezenta ntregul sistem. Deci, scopul diagramei componentelor poate fi rezumat astfel:

Vizualizati componentele unui sistem. Construirea de executabile prin utilizarea de compilare si inversa. Descriei organizarea i relaiile dintre componente.

Cum se deseneaza diagrama componentelor?

Diagramele componentelor sunt folosite pentru a descrie artefactele fizice ale unui sistem. Un astfel de artefact include imagini, executabilele, biblioteci etc Deci, scopul acestei diagrame este diferit, diagramele de componente sunt utilizate n timpul fazei de implementare a unei cereri. Dar este bine pregtit n avans pentru a vizualiza detaliile de implementare. Iniial, sistemul este proiectat folosind diagrame UML diferite i atunci cnd artefactele sunt gata diagramele componente sunt folosite pentru a obine o idee de punere n aplicare. Aceast diagram este foarte importanta, deoarece fr ea cererea nu poate fi pus n aplicare eficient. O diagram component bine pregtita este, de asemenea, importanta pentru alte aspecte precum performantele de aplicare, ntreinere etc. Deci, nainte de elaborarea unei diagrame a componentelor, trebuie sa identificam n mod clar urmtoarele artefacte:

Fiierele utilizate n sistem. Bibliotecile i alte obiecte relevante pentru punerea n aplicare. Relaiile dintre artefacte.

Acum, dup identificarea artefactelor, trebuie sa urmam urmtoarele puncte:

Utilizai un nume semnificativ pentru a identifica componenta pentru care diagrama va fi construita. Se pregateste un idee de baza nainte de producerea instrumentelor de ajutor. Utilizai note pentru a clarifica punctele importante.

Ceea ce urmeaz este o diagrama component pentru sistemul managerial de comand. Aici artefactele sunt fiiere. Deci diagrama prezinta fiierele din aplicatie i relaiile lor. n realitate diagrama de componente conine, de asemenea DLL-uri, biblioteci, foldere, etc n urmtoarea diagram patru fiiere sunt identificate i relaiile lor sunt produse. Diagrama de componente nu poate fi compensat n mod direct cu alte diagrame UML discutate pn acum. Deoarece este ntocmit n scopuri complet diferite. Deci diagrama urmtoare de componente a fost elaborata lund n considerare toate punctele menionate mai sus:

n ce cazuri folosim Diagrama de componente?

Am descris deja c diagramele componentelor sunt folosite pentru a vizualiza implementarea statica a unui sistem. Diagramele de componente sunt un tip special de diagrame UML folosite pentru scopuri diferite. Aceste diagrame arat componentele fizice ale unui sistem. Pentru a clarifica aceasta, putem spune c diagramele de componente descriu organizarea componentelor ntr-un sistem. Organizarea poate fi descrisa n continuare drept locaia componentelor ntr-un sistem. Aceste componente sunt organizate ntr-un mod special pentru a ndeplini cerinele unui sistem. Aa cum am discutat mai inainte, aceste componente sunt biblioteci, fiiere, executabilele etc. Acum, nainte de punerea n aplicare a cererii aceste componente vor fi organizate. Aceast organizaie component este, de asemenea proiectat separat, ca parte a proiectului de execuie.

Diagramele de componente sunt foarte importante din punct de vedere al implementarii. Deci, echipa de implementare a unei aplicatii ar trebui s aib o cunoatere corect a detaliilor componentei. Acum, utilizarea de diagrame componente pot fi descrise ca:

Modelarea componentelor unui sistem. Modelarea schemei bazei de date. Modelarea executabila a unei aplicatii. Modelarea codului sursa a sistemului.

Figura 8: O diagram a componentelor

3.2.1.4 Diagrama de desfurare (Deployment View)

Arhitectura fizic pe care va fi implementat sistemul, calculatoarele, device-urile (referite ca nodurile sistemului), mpreun cu conexiunile dintre ele, vor putea fi prezentate n cadrul unei diagrame de desfaurare. Componentele i obiectele executabile sunt alocate n interiorul nodurilor, ceea ce ne va permite o vizualizare a unitailor care se vor executa pe fiecare nod.

Figura 9: O diagram de desfaurare care prezint structura fizic a sistemului.

Prezentare:
Diagramele de desfurare sunt utilizate pentru a vizualiza topologia componentele fizice ale unui sistem n care componentele software sunt implementate. Asadar, diagramele de desfurare sunt folosite pentru a descrie desfasurarea statica a unui sistem, si consista din noduri si relatia intre ele.

Scop:
Numele de desfurare se descrie pe sine n scopul de diagrama. Diagramele de desfasurare sunt utilizate pentru a descrie componentele hardware in care componentele software sunt vizualizate.Aceste diagrame de desfasurare i diagramele componentelor sunt strns legate. Diagramele Componentelor sunt folosite pentru a descrie componentele i schemele de desfurare arat modul n care acestea sunt dislocate n hardware. UML este n principal destinat s se concentreze pe artefactele software ale unui sistem. Dar aceste dou diagrame sunt diagrame de construcii utilizate pentru a se concentra pe componente software i componente hardware. Deci, cele mai multe diagrame UML sunt utilizate pentru a manipula componente logice, dar diagramele de desfurare sunt fcute ca s se concentreze asupra topologiei hardware a unui sistem. Diagramele de desfurare sunt utilizate de ctre inginerii de sistem. Scopul diagramelor de desfurare pot fi descrise ca:

Vizualizarea topologiei hardware a unui sistem. Descrie componentele hardware utilizate pentru a implementa componente software. Descrie noduri runtime de prelucrare.

Cum se deseneaza diagrama de desfurare?

Diagrama de desfurare reprezint vizualizarea implementarii unui sistem. Este legata de diagrama de componente, deoarece componentele sunt dislocate cu ajutorul diagramelor de desfurare. O diagram de desfasurare/implementare este formata din noduri. Nodurile sunt nimic altceva dect produse hardware fizice utilizate pentru a implementa aplicatia. Diagrame de implementare sunt utile pentru inginerii de sistem. O diagram de implementare eficient este foarte importanta, deoarece controleaza urmtorii parametri

Performan Scalabilitate Mentenabilitatea Portabilitate

Deci, nainte de elaborarea unei diagrame de implementare ar trebuii identificate urmtoarele:

Noduri Relaiile ntre noduri

Urmatoarea diagrama de desfurare reprezinta un exemplul pentru a va da o idee legata de implementarea sistemului de management. Aici am aratat ca noduri:

Monitor Modem Caching server de Server

Aplicatia se presupune a fi o aplicaie web care este implementata ntr-un mediu cluster folosind serverul 1, 2 i serverul 3. Utilizatorul se conecteaza la aplicaie folosind internetul. Traseul se desfasoara de la serverul de caching catre mediul cu clustere. Deci, urmatoarea diagrama de desfurare a fost elaborata lund n considerare toate punctele menionate mai sus:

Unde se folosesc diagramele de desfasurare?

Diagramele de desfurare sunt folosite n principal de ctre inginerii de sistem. Aceste diagrame sunt folosite pentru a descrie componentele fizice (Hardwares), distribuirea si asocierea acestora. Pentru a clarifica acest lucru n detalii, putem vizualiza diagramele de desfurare ca i componentele hardware / nodurile pe care sunt implementate componente software. Aplicaiile software sunt dezvoltate pentru a modela procesele complexe legate de afaceri. Doar utilizarea unor aplicaii software eficiente nu sunt suficiente pentru a satisface cerinele unei afaceri. Cerinele de afaceri pot fi descrise in scopul de a sprijini creterea numrului de utilizatori, timp de rspuns rapid, etc. Pentru a satisface aceste tipuri de componente hardware, cerinele ar trebui s fie proiectate eficient i ntr-un mod rentabil. Acum, aplicaiile software sunt foarte complexe n natur; pot fi de sine statatoare, bazate pe web, distribuite, bazate pe mainframe i multe altele. Deci, este foarte important sa se proiecteze componentele hardware intr-un mod eficient.

Deci, utilizarea de diagrame de implementare poate fi descris dup cum urmeaz:

Pentru a modela topologia hardware a unui sistem. Pentru a modela un sistem integrat. Pentru a modela detalii hardware pentru un sistem client / server. Pentru a modela detalii hardware a unei aplicatii distribuite. Compilare si inversa.

3.2.2 Diagrame comportamentale

3.2.2.1 Diagrama cazurilor de utilizare (Use Case Diagram)
Use case diagram este un tip de diagram din care reiese modul de utilizare a sistemului informatic - modul n care utilizatorii interacioneaz cu acesta (n coresponden direct cu taskurile acestor utilizatori.). Utilizarea use case diagram nu este absolut necesar pentru a scrie o specificaie cu use case-uri dar este util pentru a crea o imagine general asupra sistemului.

Prezentare:
Pentru a modela un sistem, cel mai important aspect este acela de a capta comportamentul dinamic. Pentru a clarifica in detalii, prin comportamentul dinamic se nelege comportamentul sistemului atunci cnd se execut / opereaza. Deci, numai comportamentul static nu este suficient pentru a modela un sistem, comportamentul dinamic este mai important dect comportamentul static. n UML exist cinci diagrame disponibile pentru modelul de natur dinamic i diagrama caz de utilizare este unul dintre ele. Acum, ar trebuii sa discutam despre faptul c diagrama caz de utilizare este dinamica n natur, si ar trebui s existe anumiti factori interni sau externi pentru efectuarea acestei interaciuni. Aceti ageni interni i externi sunt cunoscuti drept actori. Deci, diagramele caz de utilizare se compun din actori, cazuri de utilizare i relaiile lor. Diagrama este utilizata pentru a modela sistemul / subsistem unei cereri. O singura diagrama a unui caz de utilizare captureaz o funcionalitate special a unui sistem. Deci, pentru a modela ntregul sistem sunt folosite un anumit numar de diagrame caz de utilizare.

Scop:
Scopul diagramei caz de utilizare este de a surprinde aspectul dinamic al unui sistem. Dar aceast definiie este prea generica pentru a descrie scopul, deoarece alte patru diagrame (activitate, secvena, colaborare i stare) au, de asemenea, acelai scop. Deci, ne vom orienta asupra unui scop specific, care o va distinge de celelalte patru diagrame.

Diagramele caz de utilizare sunt folosite pentru a aduna cerinele unui sistem, inclusiv influene interne i externe. Aceste cerine sunt n general cerinele de proiectare. Deci, atunci cnd un sistem este analizat pentru a aduna funcionalitile sale, cazurile de utilizare sunt pregtite i actorii sunt identificati. Cand sarcina iniial este completa, diagramele caz de utilizare sunt modelate pentru a prezenta punctul de vedere exterior. Deci, pe scurt, scopul diagramelor caz de utilizare pot fi, dup cum urmeaz:

Folosit pentru a aduna cerinele unui sistem. Folosit pentru a obine o imagine n afara unui sistem. Identificarea factorilor externi i interni care influeneaz sistemul. Arat ca cei care interacioneaz ntre cerine sunt actori.

Cum se elaboreaza diagrama caz de utilizare?

Diagramele caz de utilizare sunt luate n considerare pentru analiza de nivel nalt a unui sistem. Deci, n cazul n care cerinele unui sistem sunt analizate funcionalitile lor sunt capturate n cazurile de utilizare. Deci, putem spune c aceste cazuri de utilizare nu sunt altceva decat funcionalitile sistemului scrise ntr-un mod organizat. Acum, alte doua lucrurile care sunt relevante pentru cazuri de utilizare sunt actorii. Actori pot fi definiti ca ceva care interacioneaz cu sistemul; pot fi utilizatorii umani, unele aplicaii interne sau poate unele aplicaii externe. Deci, mai pe scurt atunci cnd planificam desenarea unei diagrame caz de utilizare trebuie s tinem cont de urmtoarele elemente identificate.

Funcionaliti de a fi reprezentate ca un caz de utilizare Actori Relaiile ntre cazurile de utilizare i de actori.

Diagramele caz de utilizare sunt trase pentru a captura cerinele funcionale ale unui sistem. Astfel, dup identificarea elementele de mai sus, trebuie s respectam liniile directoare urmtoare pentru a desena o eficienta diagrama caz de utilizare.

Numele unui caz de utilizare este foarte important. Deci, numele ar trebui s fie alese n aa fel, astfel nct s poat identifica funcionalitile efectuate. Dai un nume potrivit pentru actori. Afiare relaii i dependenele n mod clar n diagrama. Nu ncercai s includ toate tipurile de relatii. Deoarece scopul principal al schemei este de a identifica cerinele. Utilizai not atunci cnd vreodat necesare pentru a clarifica anumite puncte importante.

Ceea ce urmeaz este un exemplu al diagramei use case care reprezint sistemul de gestionare al comenzilor. Deci, dac ne uitm n diagram atunci vom gasi trei use case-uri (Order, SpecialOrder i NormalOrder) i un actor, care este clientul. Use case-urile SpecialOrder i NormalOrder sunt extinse de la case-ul Order , deci au o relatie extinsa.Un alt punct important este de a identifica graniele sistemului, care este prezentat n imagine. Actorul Customer se afl n afara sistemului deoarece acesta este un utilizator extern al sistemului.

Unde folosim diagramele use-case?

Aa cum am discutat deja sunt cinci diagrame n UML pentru a vizualiza modelul dinamic al unui sistem. Acum, fiecare model are un scop specific de a fi utilizat. De fapt, aceste scopuri specifice sunt diferite unghiuri ale unui sistem de rulare. Deci, pentru a nelege dinamica unui sistem avem nevoie de a utiliza diferite tipuri de diagrame. Diagrama use case este una dintre ele i scopul su specific este de a aduna cerinele de sistem i actori. Diagramele use case specifica evenimentele unui sistem i fluxurile lor, dar niciodat nu descrie modul n care acestea sunt implementate. Diagrama use case poate fi imaginata ca o cutie neagr n care numai intrarea, ieirea i funcia cutiei negre este cunoscuta. Aceste diagrame sunt utilizate la un nivel foarte ridicat de design, iar acest design de nivel nalt este rafinat din nou i din nou pentru a obine o imagine complet i practic a sistemului. Un use case bine structurat descrie, de asemenea, conditia pre, post si excepiile. i aceste elemente suplimentare sunt folosite pentru a face cazuri de testare atunci cnd se efectueaz testarea. Dei use case-urile nu sunt un bun candidat pentru compilare si decompilare, dar totui ele sunt folosite ntr-un mod usor diferit pentru acestea. i acelai lucru este valabil i pentru decompilare. n cazul de compilare diagramele use case se utilizeaz pentru a face cazuri de testare i, n cazurile de decompilare sunt utilizare pentru a pregti detaliile cerinelor de la aplicatia existent. Deci, acestea sunt urmtoarele locuri n care diagramele caz de utilizare sunt utilizate:

Cerina de analiz i proiectare la nivel nalt. Modelarea cadrului unui sistem. Decompilarea. Compilarea..

Elementele utilizate i notaiile lor sunt urmtoarele: Element Descriere Actor Un actor este, n principiu, un utilizator al sistemului, dar poate fi i un alt sistem informatic care interacioneaz cu sistemul analizat. Use Case-urile se reprezint sub forma unei elipse n interiorul creia este scris numele Use Case-ului respectiv. Notaie

Use Case

Asocierea este utilizat pentru a indica legtura dintre un Actor i un Asociere Use Case, n sensul c acel actor particip ntr-un fel oarecare n acel Use Case.

Un exemplu simplu de utilizare a diagramei este urmtorul:

ntre actori i use case-uri pot s existe relaii de generalizare / specializare atunci cnd un actor sau un use case poate fi asimilat unei clase de actori, respectiv de use case-uri.

Relaia de tip extensie ntre use case-uri Relaiile de tip extensie (i implicit use case-urile de extensie) se folosesc atunci cnd se modeleaz un comportament opional sau excepional, care nu condiioneaz finalitatea use caseului de baz. De exemplu, un utilizator poate, n cazuri excepionale s aleag s depun o reclamaie dup efectuarea unei comenzi:

Relaia de tip includere Relaia de tip includere se folosete atunci cnd use case-ul inclus nu este o parte esenial a fluxului din use case-ul de baz sau este un comportament care se repet n mai multe use caseuri. De pild autentificarea n sistem, dei condiioneaz introducerea unei comenzi, nu este specific introducerii comenzii i de asemenea, poate fi folosit n mai multe use case-uri:

Un caz de utilizare este o descriere a unei funcionaliti (o utilizare specific a sistemului) pe care o ofer sistemul. Diagrama prezint actorii externi i cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, aa cum este el perceput de utilizatorii lui) nu i din interior, precum i conexiunile identificate ntre actori i cazurile de utilizare. Un exemplu de diagram a cazurilor de utilizare este prezentat n figura 2.

Figura 2: O diagram a cazurilor de utilizare dintr-un sistem de asigurri.

3.2.2.3 Diagrama de activitate (Activity Diagram)

O diagram de activitate prezint fluxul secvenelor de activitai i este de obicei folosit pentru a descrie activitaile realizate n cadrul unei operaii, folosind dac este cazul decizii i condiii. Diagrama conine stri de aciune (action states), i mesaje care vor fi trimise sau recepionate ca parte a aciunii realizate. Diagrama de activitate este o diagrama importanta n UML care descrie aspectele dinamice ale sistemului. Poate fi considerata o diagram de flux care reprezinta fluxul de control de la o activitate la alta. . Acest flux poate fi secvenial, ramificat sau concurent. Diagrama de activitate se refer la toate tipurile de control al fluxului prin utilizarea diferitelor elemente. Activitatea poate fi descris ca o operaiune a sistemului.

Scop:
Scopurile de baz ale diagramei de activitate sunt similare cu cele ale celorlalte patru diagrame. Ea surprinde comportamentul dinamic al sistemului. Celelalte patru diagrame sunt utilizate pentru a afia fluxul de mesaje de la un obiect la altul, dar diagrama de activitate este utilizat pentru a arta fluxul de mesaje de la o activitate la alta. Activitatea este o operaiune special a sistemului. Diagramele de activitate nu sunt folosite numai pentru vizualizarea dinamic a naturii unui sistem, dar acestea sunt, de asemenea, utilizate pentru a construi sistemul de executabil cu ajutorul unor tehnici de compilare si decompilare. Singurul lucru care lipseste din diagrama de activitate este mesajul. Ea nu arat nici un flux de mesaje de la o activitate la alta. Diagrama de activitate este uneori considerata ca fiind un grafic de flux, si dei diagrama arata ca un grafic de flux dar nu este. Se prezinta diverse fluxuri cum ar fi ramificat paralel,concurente i singure. Deci, scopul poate fi descris ca:

Desenai activitatea fluxului unui sistem. Descriei secvena de la o activitate la alta. Descrie fluxul paralel, ramificat i concomitent al sistemului.

Cum se deseneaza diagrama de activitate?

Diagramele de activitate sunt utilizate n principal ca un grafic de flux ce consista din activiti desfurate de ctre sistem. Dar, diagrama de activitate nu este tocmai un grafic de flux, deoarece prezinta anumite capaciti suplimentare. Aceste capaciti suplimentare includ ramificare, flux paralel, swimlane etc nainte de ntocmirea unei diagrame de activitate trebuie s avem o nelegere clar cu privire la elementele folosite n diagrama de activitate. Elementul principal al unei diagrame de activitate este activitatea n sine. O activitate este o funcie realizat de ctre sistem. Dup identificarea activitilor avem nevoie s nelegem modul n care acestea sunt asociate cu constrngeri i condiii.

Deci, nainte de desenarea unei diagrame de activitate, ar trebui s identificam urmtoarele elemente:

Activiti Asociaie Starea Restrictii

Odata ce parametrii de mai sus sunt identificati avem nevoie pentru a face o imagine mentala a ntregului flux. Aceasta imagine mentala este apoi transformat ntr-o diagram de activitate. Ceea ce urmeaza este un exemplu de diagrama de activitate pentru sistemul de management comand. n diagrama, patru activiti sunt identificate care sunt asociate cu condiii. Un aspect important ce ar trebui neles n mod clar este c o diagrama de activitate nu poate fi compensat exact cu codul. Diagrama de activitate este facuta pentru a intelege fluxul de activiti i, utilizata n principal de ctre utilizatorii de afaceri. Diagrama de mai jos este reprodusa cu patru activiti principale:

Trimite o comand de ctre client Primeste ordinului de comanda Confirmare comand Expedierea comand

Dup primirea cererii sunt efectuate condiia de Order pentru a verifica dac aceasta este SpecialOrder sau NormalOrder. Dup ce tipul de ordin este identificat, activitatea de expediere este efectuat i acest lucru este marcat de ncetarea procesului.

Unde s utilizai diagrame de activitate?

Utilizarea de baz a diagramei de activitate este similara cu cea a celorlalte patru diagrame UML. Uzajul specific este de a modela fluxul de control de la o activitate la alta. Acest flux de control nu include mesaje. Diagrama de activitate este potrivita pentru modelarea fluxului de activitate al sistemului. O aplicatie poate avea mai multe sisteme. Diagrama de activitate surprinde, de asemenea, aceste sisteme i descrie fluxul de la un sistem la altul. Acest lucru specific de utilizare nu este disponibil n alte diagrame. Aceste sisteme pot fi de baze de date, cozi de externe sau orice alt sistem. Acum ne vom uita n aplicaiile practice ale diagramei de activitate. Din discuia de mai sus, este clar c o diagrama de activitate este trasat de la un nivel foarte ridicat. Deci, va da o vedere de nivel ridicat al unui sistem. Acest punct de vedere la nivel nalt este n principal pentru utilizatorii de afaceri sau orice alt persoan care nu este o persoan tehnic. Aceast diagram este folosita pentru a modela activitile care nu sunt altceva dect cerinele de afaceri. Deci diagrama are un impact mai mare pe nelegerea de afaceri mai, decat pe detaliile de implementare. Urmatoarele sunt uzurile principale ale diagramei de activitate:

Modelarea fluxului de lucru prin utilizarea de activiti. Modelarea cerintelor de business. nelegere la nivel nalt a funcionalitilor sistemului. Investigheaza cerinele de business ntr-o etap ulterioar.

Figura 8: O diagram de activitate pentru un server de imprimant.

3.2.2.3 Diagrama de stare (State Diagram)

Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stri prin care poate trece un obiect i modul n care se poate trece de la o stare la alta (modelare work-flow-uri, modelare fluxuri de documente, diagrame de stri).

Prezentare:
Trecerea de la o stare la alta este determinat de tranzaciile intermediare - acestea corespund aciunilor pe care le-am ntlnit la Activity Diagram ( Statechart Diagram reprezint intr-un fel un alt mod de a vedea un flux ce poate fi modelat exclusiv prin Activity Diagram, inventat pentru a exprima mai elocvent trecerile de la o stare la alta). Numele diagramei n sine clarific scopul de diagram i alte detalii. Acesta descrie diferite stri ale unei componente ntr-un sistem, aceste stari sunt specifice pentru o component / obiectul unui sistem. O diagram Statechart descrie o main de stare. Acum, pentru a clarifica aceasta, maina de stare poate fi definit ca o main care definete diferite stri ale unui obiect i aceste stari sunt controlate de evenimente externe sau interne. Diagrama de activitate explicata n capitolul anterior, este un tip special de diagram Statechart. Deoarece diagrama Statechart definete stari este folosita pentru a modela durata de viata a unui obiect.

Scop:
Diagrama Statechart este una dintre cele cinci diagrame UML utilizate pentru a modela natura dinamic a unui sistem. Ele definesc diferite stri ale unui obiect n timpul vieii sale. i aceste stari sunt modificate de evenimente. Deci, diagrame Statechart sunt utile i pentru sistemele reactive modelului. Sistemele reactive pot fi definite ca un sistem care rspunde la evenimente externe sau interne. Diagrama Statechart descrie fluxul de control de la o stare la alta. Starile sunt definite ca o conditie in care un obiect exist i se schimb atunci cnd un eveniment este declanat. Deci, scopul cel mai important al diagramei Statechart este de a modela durata de via a unui obiect de la creatie pana la terminare. Diagramele Statechart sunt, de asemenea, utilizate pentru compilarea si decompilarea unui sistem. Dar scopul principal este acela de a modela sistemul reactiv. Principalele scopuri ale folosirii diagrame Statechart sunt:

Pentru modelarea aspectul dinamic al unui sistem. Pentru modelarea duratei de viata al unui sistem reactiv. Pentru a descrie diferite stri ale unui obiect n timpul duratei sale de via. Definii o main de stare pentru a modela starile unui obiect.

Cum se deseneaza diagrama Statechart?

Diagrama este folosita pentru a descrie strile unor diferite obiecte diferite n ciclul lor de via. Astfel, accentul este pus pe seama modificrilor de stare asupra unor evenimente interne sau externe. Aceste stri de obiecte sunt importante pentru a analiza i a le pune n aplicare cu acuratee. Starile pot fi identificate ca fiind conditia obiectelor atunci cnd un anumit eveniment are loc. nainte de ntocmirea unei diagrame Statechart trebuie s avem clarificate urmtoarele puncte:

Identifica obiectele importante pentru a fi analizate. Identifica starile. Identifica evenimentele.

Urmtorul este un exemplu de diagram Statechart n cazul n care starea de obiect Order este analizata. Prima stare este o starea de repaus, de unde ncepe procesul. Starile urmtoare apar pentru evenimente cum ar fi cerere trimitere, cerere confirmare, i expediere comanda. Aceste evenimente sunt responsabile pentru schimbarile starilor ale unor obiecte. n timpul ciclului de via al unui obiect, se trece prin urmtoarele stri i pot exista de asemenea, niste iesiri anormale. Aceste ieiri anormale pot s apar din cauza unor probleme n sistem. Atunci cand ntregul ciclu de via este complet, este considerat ca tranzacia complet dup cum se menioneaz mai jos. Starea iniial i final a unui obiect este, de asemenea, prezentata mai jos.

Cand folosim diagrame Statechart?

Din discuia de mai sus putem defini aplicaiile practice ale unei diagrame Statechart. Diagrame Statechart sunt folosite pentru a modela aspectul dinamic al unui sistem ca alte patru diagrame

dezafectate n acest tutorial. Dar are unele caracteristici distinctive pentru modelarea natur dinamic. Diagrama Statechart definete strile unei componente i modificrile acestei stari sunt dinamice n natur. Deci, scopul su specific este de a defini schimbarile de stari declanate de evenimente. Evenimentele sunt factori interni sau externi care influeneaz sistemul. Diagramele Statechart sunt utilizate pentru a modela starile i, de asemenea, evenimentele de operare pe sistem. Atunci cnd se implementeaza un sistem este foarte important s se clarifice diferitele stri ale unui obiect n timpul vieii sal, iar diagramele statechart sunt folosite n acest scop. Atunci cnd aceste stari i evenimente sunt identificate acestea sunt utilizate pentru a modela i aceste modele sunt folosite n timpul punerii n aplicare a sistemului. Dac ne uitm la punerea n practic a diagramei Statechart, atunci este folosit n principal pentru a analiza starile obiectului influenat de evenimente. Aceast analiz este utila pentru a nelege comportamentul sistemului n timpul execuiei sale. Principale uzaje pot fi descrise ca:

Pentru a modela starile obiectului unui sistem. Pentru a modela un sistem reactiv. Sistemul reactiv const n obiecte reactive. Pentru a identifica evenimentele responsabile pentru modificrile de stare. Compilare si decompilare.

De exemplu o comand primit de la un client poate fi iniial n stare de ateptare, pentru ca un operator s verifice bonitatea clientului i stocul i s accepte comanda. Dup acceptare, se poate produce livrarea produselor comandate i comanda trece n starea de comand livrat dup care urmeaz facturarea i nchiderea comenzii. Elementele utilizate i notaiile lor sunt urmtoarele: Element Stare Stare iniial Stare final Tranziie Descriere Indic starea n care se gsete obiectul la un moment dat. Reprezint punctul de intrare sau punctul n care obiectul este iniiat. Punctul iniial este unic. Reprezint punctul de final cnd starea obiectului nu se mai modific. Tranziia reprezint trecerea de la o stare la alta, provocat de apariia unui anumit eveniment. Notaie

n afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie i aciunile paralele (asincrone) la Activity diagram. n figura de mai jos este exemplu de folosire a elementelor specifice statechart diagram, pentru cazul unei comenzi:

Interpretarea acestei diagrame se gsesc despre Activity Diagram.

Figura5 O stare este de obicei un complement al descrierii unei clase. Asadar, o diagram de stare prezint toate strile prin care trece un obiect al clasei precum i evenimentele care-i cauzeaz

modificrile de stare. Modificarea strii se numete tranziie. Un exemplu de diagram de stare este prezentat n figura 5. Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea care au un numr de stri bine definit iar comportamentul clasei este afectat i modificat de acestea.

3.2.2.4 Diagrama de interactiune (Interaction Diagram)

Prezentare:
Din numele de Interaciune, este clar faptul c diagrama este utilizata pentru a descrie un anumit tip de interaciuni ntre diferitele elemente ale modelului. Deci, aceast interaciune este o parte a comportamentului dinamic al sistemului.Acest comportament interactiv este reprezentat n UML de ctre cele dou diagrame cunoscut sub numele de diagrama de secventa i diagrama de colaborare. Scopurile de baz ale ambelor diagrame sunt similare. Diagrama de secven pune accent pe secvena de timp a mesajelor i diagrama de colaborare pune accentul pe organizarea structural a obiectelor care trimit i primesc mesaje.

Scop:
Scopul diagramelor de interaciune este de a vizualiza comportamentul interactiv al sistemului. Acum, vizualizarea interaciunii este o sarcin dificil. Deci, soluia este de a utiliza diferite tipuri de modele pentru a surprinde diferite aspecte ale interaciunii. Acesta este motivul pentru care diagramele de secventa si colaborare sunt folosite pentru a capta natura dinamica, dar dintr-un unghi diferit. Deci, scopurile diagramei de interaciune pot fi descrie ca fiind:

Pentru a capta comportamentul dinamic al unui sistem. Pentru a descrie fluxul de mesaje n sistem. Pentru a descrie organizarea structural a obiectelor. Pentru a descrie interaciunea dintre obiecte.

Cum se deseneaza diagrama de interaciune?

Aa cum am discutat deja, scopul diagramelor de interaciune sunt pentru a surprinde aspectul dinamic al unui sistem. Deci, pentru a captura aspectul dinamic avem nevoie s nelegem ce este un aspect dinamic i modul n care este vizualizat. Aspectul dinamic poate fi definit ca o imagine de moment a sistemului care ruleaz la un moment dat. Avem dou tipuri de diagrame de interaciune n UML. Una este diagrama de secven, iar cealalta este o diagrama de colaborare. Diagrama de secven surprinde secvena de timp a fluxului de mesaj de la un obiect la altul i diagrama de colaborare descrie organizarea de obiecte ntr-un sistem care ia parte la un flux de mesaje.

Deci, lucrurile enumerate mai jos sunt identificate n mod clar nainte de desenarea diagramei de interaciune:

Obiecte care iau parte la interaciune. Fluxurile de mesaje printre obiecte. Secvena n care mesajele se transmit. Organizarea obiectului

Voi prezenta in urmatoarele randuri dou diagrame de interaciune pentru modelarea sistemului de management. Prima diagrama este o diagrama secven, iar a doua este o diagrama de colaborare.

3.2.2.4.1 Diagrama de Secventa (Sequence Diagram)

Diagrama de secventa prezinta patru obiecte (Customer, Order, SpecialOrder i NormalOrder). Diagrama de mai jos a artat secvena de mesaje pentru obiectul SpecialOrder i acelai lucru poate fi utilizat n cazul obiectului NormalOrder. Acum este important s se neleag secvena de timp a fluxurilor de mesaj. Fluxul de mesaje nu este altceva decat un apel de metoda a unui obiect. Primul apel este sendOrder (), care este o metod a obiectului Order. Urmtorul apel este confirm (), care este o metod a obiectului SpecialOrder i ultima cerere este Dispatch (), care este o metod a obiectului SpecialOrder. Deci, aici diagrama descrie n principal, metoda de apeluri de la un obiect la altul i acest lucru este, de asemenea, scenariul real atunci cnd sistemul este pornit.

Obiectele sunt vzute ca linii verticale distribuite pe orizontal, iar timpul este reprezentat pe axa vertical de sus n jos. Mesajele sunt reprezentate prin sgei ntre linile

verticale ce corespund obiectelor implicate n mesaj.

Figura 6: Diagrama de secven pentru un server de imprimant

3.2.2.4.2 Diagrama de colaborare (Collaboration Diagram)

A doua diagrama de interactiune este diagrama de colaborare.Aceasta prezinta organizarea obiectelor aa cum se arat mai jos. Aici, n diagrama de colaborare, secvena metodei de apel este indicat printr-o tehnica de numerotare dup cum se arat mai jos. Numrul indic modul n care metodele sunt solicitate una dup alta. Am luat acelai sistem de management pentru a descrie diagrama de colaborare. Cum decidem ce tip de diagram s folosim? Dac cel mai important aspect este timpul sau secvena de mesaje vom folosi diagrama de secven, dar dac trebuie scos n evident contextul, vom apela la o diagram de colaborare. Metodele solicitate sunt similare cu cea a unei diagrama secven. Dar diferena este c diagrama de secven nu descrie organizarea obiectelor, in timp ce diagrama de colaborare prezinta organizarea obiectelor. Acum, pentru a alege ntre aceste dou diagrame, accentul principal este dat de tipul de cerin. n cazul n care secvena de timp este importanta, atunci diagrama de secventa este utilizata i n cazul n care organizarea este necesar, atunci diagrama de colaborare este utilizata.

Desenarea unei diagrame de colaborare se face similar cu a unei diagrame a obiectelor. Mesajele vor fi reprezentate prin sgei ntre obiectele implicate n mesaj i pot fi nsoite de etichete care specific ordinea n care acestea vor fi transmise. De asemenea se pot vizualiza condiii, iteraii, valori returnate, precum i obiectele active care se execut concurent cu alte obiecte active (vezi figura 7).

Figura 7: O diagram de colaborare pentru un server de imprimant.

Cand folosim diagramele de interaciune?

Am discutat deja c diagramele de interaciune sunt folosite pentru a descrie natura dinamic a unui sistem. Acum ne vom uita n scenariile de practic n cazul n care aceste diagrame sunt folosite. Pentru a nelege aplicarea n practic avem nevoie s nelegem natura de baz a secvenei i diagrama de colaborare. Principalele scopuri ale ambelor diagrame sunt similare, deoarece ambele sunt folosite pentru a capta comportamentul dinamic al unui sistem. Dar scopurile specifice sunt mai importante pentru a clarifica i a intelege. Diagramele de secventa sunt utilizate pentru a captura ordinea de mesaje care se transmit de la un obiect la altul. i diagramele de colaborare sunt folosite pentru a descrie organizarile structurale ale obiectelor care iau parte la interaciune. O singura diagram nu este suficient

pentru a descrie aspectul dinamic al unui ntreg sistem, astfel este folosit un set de diagrame pentru a captura tot sistemul ca un ntreg. Diagramele de interaciune sunt utilizate atunci cnd vrem s nelegem fluxul de mesaje i organizarea structural. Acum, flux de mesaje nseamn secvena de debit de la un obiect la altul i organizarea structural nseamn organizarea vizuala a elementelor ntr-un sistem. Acestea sunt urmtoarele intrebuintari ale diagramei de interaciune:

Pentru a modela fluxul de control de ctre secvena de timp. Pentru a modela fluxul de control de ctre organizarile structurale. Pentru compilare. Pentru decompilare.

4. Concluzii
Cu multi ani in urma, programatorii dezvoltau diverse programe fr o bun analiz i o bun proiectare a respectivelor programe. Avand in vedere ca faza de analiz i proiectare a unui sistem informatic trebuie s fie gata nainte de realizarea codului, era necesara o atenie mrit din partea dezvoltatorilor. Multe dintre aceste etape au fost ignorate n trecut, dar cu timpul dezvoltatorii au inceput sa recunoasca importana acestor faze, deoarece s-a dovedit c de acestea depinde producerea de software adecvat i competitiv. Limbajele de modelare au fost create pentru analiza i proiectarea sistemelor, iar unul din aceste limbaje de modelare este limbajul de modelare unificat - UML (The Unified Modeling Language). El reprezinta limbajul universal standard pentru dezvoltatorii software din toat lumea. UML este foarte popular si folosit deoarece deine o expresivitate foarte buna care ajut la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. UML ofer arhitecturi de sisteme ce funcioneaz pe analiza i proiectarea obiectelor cu un limbaj corespunztor pentru specificarea, vizualizarea, construirea i documentarea. Notaiile UML constituie un element esenial al limbajului pentru realizarea propriu-zis a modelrii i anume, partea reprezentrii grafice pe care se bazeaz orice limbaj de modelare. Mai pe scurt, ideea de baza este ca este absolut necesar s cunoatem principalele elemente ale unui limbaj de modelare nainte de a iniia proiectarea i dezvoltarea unui sistem.

5.Bibliografie
http://www.techit.ro/tutorial_uml.php http://www.scribd.com/doc/46196747/Uml http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf http://www.tutorialspoint.com/uml/uml_component_diagram.htm Gheorghe Andrei Avram (2002) - Sisteme informationale, Editura Aisteda MasteringUMLwithRationalRose2002 Wiley - Enterprise Java with UML Bdard, Y. (1999) - Visual Modeling of Spatial Databases: Towards Spatial PVL and UML, Geomatica, vol. 53, no. 2, pg. 169-186; Brown, A.W. .a. (1994) - Principles of CASE Tool Integration, Oxford University Press, Oxford; Fowler, M. (2000) - UML Distilled, A Brief Guide to the Standard Object Modeling Language, Addison-Wesley; Gheorghie, O., Apetrei, A. (2003) - Ingineria Programrii, Facultatea de Informatic, Universitatea "Al. I. Cuza", Iai; Giurc, A. (2004) - Proiectare n UML, Universitatea din Craiova, Facultatea de Matematic - Informatic; Ioni, A.D. (2003) - Modelarea UML n ingineria sistemelor de programe, Ed. BIC ALL, Bucureti, 2003

Repartizarea documentatiei: Berevoianu Adelina

3.2.2 Diagrame comportamentale 3.2.2.1 Diagrama cazurilor de utilizare (Use Case Diagram) 3.2.2.2 Diagrama de activitate (Activity Diagram) 3.2.2.3 Diagrama de stare (State Diagram) 3.2.2.4 Diagrama de interactiune (Interaction Diagram) 3.2.2.4.1 Diagrama de Secventa (Sequence Diagram) 3.2.2.4.2 Diagrama de Colaborare ( Collaboration Diagram)

Epure Adriana
3.2.1 Diagrame structurale 3.2.1.1 Diagrama claselor (Class Diagram) 3.2.1.2 Diagrama obiectelor (Object Diagram) 3.2.1.3 Diagrama componentelor (Component Diagram) 3.2.1.4 Diagrama de desfurare (Deployment View)

Tinta Mihaita
1. Introducere 2. Strategii de formalizare 2.1 Arhitectura UML 2.2 Modele 3. Modelarea cu UML 3.1 View-uri 4. Concluzii