UNIVERSITAREA "POLITEHNICA" BUCURESTI

Facultatea Electronica, Telecomunicatii si Tehnologia Informatiei

Referat Inginerie Software

UML

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 desfasurare (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 in domeniul software, dedicat construirii sistemelor complexe si realizarii documentelor de specificatii, facand referire in mare parte la vizualizarea, specificarea, construirea si documentarea sistemelor de aplicatii. Prezinta si limitari cu privire la generarea codului si reprezinta de asemenea un mijloc bun pentru domeniul ingineriei programarii.

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 reuneste cele mai bune tehnici si practici din domeniul ingineriei programarii, care si-au dovedit eficienta in 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 intreg sprijinul semantic si vizual pentru a inlocui 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 in intreprinderi. 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 proprietatile structurale si dinamice ale unui sistem software. Prin sistem software se intelege o BD sau un modul de cod in general. Spre deosebire de modelul EAE, UML este o colectie de tehnici de modelare, folosite pentru tratarea multor aspecte ale procesului de concepere si dezvoltare a software-ului, de la proiectarea BD la interactiunea modulelor de cod.

Fiecare tehnica de modelare de mai sus da o vedere diferita, statica sau dinamica, a unei aplicatii. Colectia de vederi se numeste model. Iata unele din tehnicile de modelare UML: diagrame de clase, sau diagrame statice de structura, care modeleaza entitatile unui sistem prin clase cu atribute si comportare. Diagramele de clasa descriu, de asemenea, asocierile dintre clase si constrangerile asupra acestora. Apoi, alte tehnici: diagrame de obiecte, diagrame de 'caz de utilizare', diagrame de stare, diagrame de secvente, 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 in acest limbaj se realizeaza prin combinarea notatiilor UML in 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 in parte.

Adoptarea specificatiei UML ca limbaj standard de modelare a fost semnalata la 17 noiembrie 1997.

În ingineria mecanica pentru a realiza modelul complet al unei piese, inginerul foloseste desenul tehnic ca limbaj pentru comunicare, iar ca mod de reprezentare, vederea in epura. Aceasta vedere in epura inseamna vizualizarea unei piese din trei puncte (din fata, de sus si din lateral) astfel incat piesa sa fie definita complet. Un cititor avizat al desenului in epura va sti intotdeauna sa refaca mental piesa desenata.

Daca din cauza complexitatii piesei, cele trei "fotografii" nu sunt suficiente, inginerul va desena si alte detalii, sau sectiuni ale piesei, dar privite din aceleasi trei unghiuri. Fiecare dintre cele trei puncte de vizualizare a piesei (noi le vom zice, view-uri) reprezinta un submodel capabil sa descrie o parte a piesei, dar insuficient pentru a descrie complet piesa. Fiecare view arata piesa vazuta dintr-un anumit punct de vedere iar modelul complet utilizeaza toate punctele de vedere relevante.

Asa cum inginerul proiectant comunica prin desen tehnic, echipei, sau oricarei alte persoane interesate intr-un limbai standard, vizual (adica desenul tehnic), facut sa permita descrierea completa dar, in acelasi timp, scutita de detalii inutile, inginerii software pot comunica cu maxima eficienta Tn limbajul UML.

La fel ca oricare limbai acesta trebuie invatat si exersat astfel incat fiecare "cuvant sa fie inteles, sa stim unde si cum se foloseste, astfel incat sa ne putem exprima in "fraze coerente, care sa "spuna' exact ceea ce vrem sa comunicam. Limbajul UML ne permite realizarea mai multor figuri, ca niste fotografii din diverse unghiuri, ale unei realitati, astfel incat aceasta realitate sa fie surprinsa prin toate aspectele ei relevante. In software vom utiliza doua puncte de vedere necesare unei descrieri suficiente a realitatii: (1) structural si (2) comportamental.

În standardul UML sunt definite urmatoarele diagrame, pe cele doua categorii:

1. pentru descrierea structurala:
   - Class Diagram;
   - Object Diagram;
   - Component Diagram;
   - Deployment Diagram.
2. pentru descrierea comportamentala:
   - Use Case Diagram;
   - Activity Diagram;
   - Statechart Diagram;
   - Sequence Diagram;
   - Collaboration Diagram.
   
   

2. Strategii de formalizare

2.1 Arhitectura UML

Pentru a intelege arhitectura UML luam in considerare modul in care programele si limbajele de programare sunt relationate intre ele. Exista multe limbaje de programare, iar fiecare program in parte este dezvoltat utilizand 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 intr-o multime de modele relationate. Conceptele limbajelor de programare sunt, la randul lor definite in metamodel. Fiecare limbaj de programare este definit printr-un model care utilizeaza si specializeaza conceptele din interiorul metamodelului. Fiecare program implementat intr-un limbaj de proiectare poate fi definit intr-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 randul lor limbaje de programare si modele utilizator care sa reprezinte programe, exemplifica arhitectura UML. UML este definit in 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, incluzand 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 in 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 intelese 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 in care este realizata solutia. Este cunoscuta si ca perspectiva fizica;

Se pot defini si alte perspective, in cazul in 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 in concordanta cu ghidurile date de exprimarea idiomurilor necesare utilizarii. Diagrame

Diagramele prezinta cunostinte intr-o forma comunicabila. UML furnizeaza urmatoarele diagrame, organizate in 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 in secventa temporale

diagrame de colaborare care descriu o interactiune de-a lungul elementelor unui sistem si a relatiilor acestora, organizate in 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 in ce mai precise si ceea ce este mai important, din ce in 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 in 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 in 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 intr-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 decat 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 in jurul deciziei si descrise utilizand UML astfel incat pot fi comunicabile si plasate pe diferite nivele.

3. Modelarea cu UML

Conceptele folosite in cadrul diagramelor UML se numesc elemente de modelare. Un element de modelare are o semantica, o definitie formala a elementului sau un inteles exact a ceea ce reprezinta el intr-un anumit context, si o reprezentare grafica, sau un simbol grafic cu care se reprezinta in cadrul diagramelor.

Un element poate fi regasit in mai multe tipuri de diagrame si pentru fiecare context exista propriile reguli. În figura 1 sunt prezentate cateva exemple de elemente de modelare impreuna cu modul lor de reprezentare.

A modela cu UML inseamna a construi mai multe modele pentru diferitele faze ale dezvoltarii si pentru diverse scopuri.

Exista mai multe faze ce trebuie parcurse:

faza de analiza - surprinde necesitatile sistemului si modeleaza clasele de baza din 'lumea reala' si colaborarile dintre acestea;

faza de design - se detaliaza modelul din faza de analiza si se formuleaza o solutie tehnica luand in considerare caracteristicile mediului in care acesta va fi reprezentat;

faza de implementare - modelul este transpus in cod iar apoi compilat in programe;

modelul de desfasurare - se foloseste o descriere care explica modul cum va fi adaptat sistemul arhitecturii fizice concrete.

Analiza unei aplicatii implica realizarea mai multor categorii de modele, dintre care cele mai importante sunt:

W      Modelul de utilizare. realizeaza modelarea problemelor si a solutiilor acestora in maniera in care le percepe utilizatorul final al aplicatiei. Diagrama asociata: diagrama de cazuri de utilizare

Modelul structural: se realizeaza pe baza analizei statice a problemei si descrie proprietatile statice ale entitatilor care compun domeniul problemei. Diagrame asociate: diagrama de module, diagrama de clase

Modelul comportamental: priveste descrierea functionalitatiilor si a succesiunii in timp a actiunilor realizate de entitatile domeniului problemei. Diagrame asociate: diagrama

(harta) de stari, diagrama de colaborare, diagrama de interactiune

Principalele parti ale UML sunt:

Vederile (View) - surprind aspecte particulare ale sistemului de modelat. Un view este o abstractizare a sistemului, iar pentru construirea lui se foloseste un numar de diagrame.

Diagramele - sunt grafuri care descriu continutul unui view. UML are noua tipuri de diagrame, care pot fi combinate pentru a forma toate view-urile sistemului.

Elementele de modelare - sunt conceptele folosite in diagrame care au corespondenta in programarea orientata-obiect, cum ar fi: clase, obiecte, mesaje si relatii intre acestea: asocierea, dependenta, generalizarea. Un element de modelare poate fi folosit in mai multe diagrame diferite si va avea acelasi inteles si acelasi mod de reprezentare.

Mecanismele generale - permit introducerea de comentarii si alte informatii despre un anumit element

3.1 View-uri

Modelarea unui sistem poate fi o munca foarte dificila. Ideal ar fi ca pentru descrierea sistemului sa se foloseasca un singur graf, insa de cele mai multe ori acesta nu poate sa surprinda toate informatiile necesare descrierii sistemului. Un sistem poate fi descris luand in considerare diferite aspecte:

v    Functional: este descrisa structura statica si comportamentul dinamic al sistemului;

v    Non-functional: necesarul de timp pentru dezvoltarea sistemului

v    Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;

Asadar pentru descrierea unui sistem sunt necesare un numar de view-uri, fiecare reprezentand o proiectie a descrierii intregului sistem si care reflecta un anumuit aspect al sau. Fiecare view este descris folosind un numar de diagrame care contin informatii relative la un anumit aspect particular al sistemului. Aceste view-uri se acopera unele pe altele, deci este posibil ca o anumita diagrama sa faca parte din mai multe view-uri.

Figura 1: View-urile din UML

VIEW UL CAZURILOR DE UTILIZARE (USE CASE VIEW Acest view surprinde functionalitatea

sistemului, asa cum este ea perceputa de actorii externi care interactioneaza cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. În componenta lui intra diagrame ale cazurilor de utilizare si ocazional, diagrame de activitate. Cei interesati de acest view sunt deopotriva clientii, designerii, dezvoltatorii dar si cei care vor realiza testarea si validarea sistemului.

VIEW UL LOGIC (LOGIC VIEW Spre deosebire de view-ul cazurilor de utilizare, un view logic

'priveste' inauntrul sistemului si descrie atat structura interna a acestuia (clase, obiecte si relatii) cat si colaborarile care apar cand obiectele trimit unul altuia mesaje pentru a realiza functionalitatea dorita. Structura statica este descrisa in diagrame de clasa, in timp ce pentru modelarea dinamicii sistemului se vor folosi diagramele de stare, de secventa, de colaborare sau de activitate. Prin urmare, cei care sunt interesati de acest tip de vizualizare a sistemului sunt designerii si dezvoltatorii.

VIEW UL COMPONENTELOR (COMPONENT VIEW Componentele sunt module de cod de

diferite tipuri. În functie de continutul lor acestea pot fi: componente care contin cod sursa, componente binare sau excutabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem si dependentele ce exista intre ele, precum si resursele alocate acestora si eventual alte informatii administrative, cum ar fi de exemplu un desfasurator al muncii de dezvoltare. Este folosit in special de dezvoltatorii sistemului, iar in componenta sa intra diagrame ale componentelor.

VIEW UL DE CONCURENTA (CONCURENT VIEW Sistemul poate fi construit astfel incat sa ruleze pe mai multe procesoare. Acest aspect, care este unul nonfunctional, este util pentru o gestionare eficienta a resurselor, executii paralele si tratari asincrone ale unor evenimente din sistem, precum si pentru rezolvarea unor probleme legate de comunicarea si sincronizarea theadu-urilor. Cei care sunt interesati de o astfel de vizualizare a sistemului sunt dezvoltatorii si integratorii de sistem, iar pentru construirea lui se folosesc diagrame dinamice (stare, secventa, colaborare si activitate) si diagrame de implementare (ale componentelor sau de desfasurare).

VIEW UL DE DESFASURARE (DEPLOYMENT VIEW Desfasurarea fizica a sistemului, ce calculatoare si ce device-uri (numite si noduri) vor fi folosite pentru realizarea efectiva a implementarii, cum sunt acestea conectate, precum si ce componente se vor executa pe fiecare nod (de exemplu ce program sau obiect este executat pe fiecare calculator), toate sunt surprinse in view-ul de desfasurare. Aceast tip de vizualizare a sistemului prezinta interes sunt dezvoltatori, integratorii de sistem si cei care realizeaza testarea sistemului, iar pentru construirea view-ului este folosita diagrama de desfasurare.

3.2 Diagrame

În UML sunt noua tipuri de diagrame, care vor fi prezentate pe larg in cele ce urmeaza. Diagramele UML pot fi impartite in: diagrame pentru modelarea structurii statice si diagrame pentru modelarea comportamentului.

Diagramele structurale sunt folosite pentru a vizualiza, specifica, construi si documenta aspectele statice ale sistemului. Acestea sunt organizate in jurul grupelor majore de

elemente ce

pot fi gasite in modelarea unui sistem. Din aceasta categorie fac parte:

Diagrama claselor (Class Diagram) - prezinta structura fizica a claselor identificate in sistem. Clasele reprezinta 'lucruri' gestionate de sistem. Este cel mai utilizat tip de diagrame in modelarea sistemelor orientate obiect.

Diagrama componentelor (Component Diagram) - prezinta structura fizica a codului in termenii componentelor de cod. Se foloseste pentru a ilustra vederea statica de implementare a unui sistem.

Diagrama obiectelor (Object Diagram) - este o varianta a diagramei claselor care, in locul unei clase, prezinta mai multe instante ale ei.

Diagrama de stare (State Diagram) - prezinta toate starile prin care trece un obiect al clasei, precum si evenimentele care-i cauzeaza modificarile de stare.

Diagramele comportamentale sunt folosite pentru a vizualiza, specifica, construi si documenta

aspectele dinamice ale unui sistem. Acestea sunt organizate in jurul modalitatilor

principale de a

modela dinamica unui sistem. Din aceasta categorie fac parte:

Diagrama cazurilor de utilizare (Use Case Diagram) - prezinta actorii externi si cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, asa cum este el perceput de utilizatorii lui ?) nu si din interior, precum si conexiunile identificate intre actori si cazurile de utilizare.

Diagrama de secventa (Sequence Diagram) - prezinta colaborarea dinamica intre un numar de obiecte, mai precis, secventele de mesaje trimise intre acestea, pe masura scurgerii timpului.

Diagrama de colaborare (Collaboration Diagram) - surprinde colaborarea dinamica intre obiecte, intr-o maniera similara cu a diagramei de secventa, dar pe langa schimbul de mesaje (numit si interactiune) prezinta obiectele si relatiile dintre ele (cateodata referite ca si context).

Diagrama de activitate (Activity Diagram) - prezinta fluxul secventelor de activitati si este de obicei folosita pentru a descrie activitatile realizate in cadrul unei operatii, folosind daca este cazul decizii si conditii.

Diagrama de tranzitie - se foloseste pentru a ilustra vederea dinamica a unui sistem. Cum luam decizia folosirii unui anumit tip de diagrama ? Daca cel mai important aspect este timpul sau secventa de mesaje vom folosi diagrama de secventa, dar daca trebuie scos in evidenta contextul, vom apela la o diagrama de colaborare. Mesajele vor fi reprezentate prin sageti intre obiectele implicate in mesaj si pot fi insotite de etichete care specifica ordinea in care acestea vor fi transmise. De asemenea, se pot vizualiza conditii, iteratii, valori returnate, precum si obiectele active care se executa concurent cu alte obiecte active.

Diagramele sunt grafuri care prezinta simboluri ale elementelor de modelare (model element) aranjate astfel incat sa ilustreze o anumita parte sau un anumit aspect al sistemului. Un model are de obicei mai multe diagrame de acelasi tip. O diagrama este o parte a unui view specific, dar exista posibilitatea ca o diagrama sa faca parte din mai multe view-uri, in functie de continutul ei. În UML sunt noua tipuri de diagrame pe care le vom prezenta in cele ce urmeaza.

3.2.1 Diagrame structurale

3.2.1.1 Diagrama claselor (Class Diagram)

O diagrama a claselor prezinta structura fizica a claselor identificate in sistem. Clasele reprezinta 'lucruri' gestionate de sistem; clasele pot fi legate in mai multe moduri: asociate

(conectate intre ele), dependente (o clasa depinde/foloseste o alta clasa), specializate (o clasa este specializarea altei clase) sau impachetate (grupate impreuna in cadrul unei unitati). Toate aceste relatii se materializeaza in structura interna a claselor in atribute si operatii.

Diagrama este considerata statica, in sensul ca este valida in orice moment din ciclul de viata al sistemului.

Class diagram este un tip de diagrama utilizata pentru descrierea structurii statice, adica a entitatilor sau claselor existente intr-un sistem. Acest tip de diagrama este utilizat cel mai adesea de catre dezvoltatori pentru specificarea claselor dar poate fi foarte util si pentru specificarea structurii unor sisteme sau subsistem dintr-un business real.

Diagrama de clase nu este utilizata doar pentru vizualizarea, descrierea si documentarea diferitelor aspecte ale unui sistem, ci, de asemenea, pentru construirea codului executabil al aplicatiei software. Ea descrie atributele si operatiunile unei clase si, de asemenea, constrangerile impuse asupra sistemului. Schemele de clasa sunt utilizate pe scara larga in 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, interfete, asociatii, colaborari si constrangeri. De asemenea, este cunoscuta ca o diagrama structurala.

Scop:

Scopul diagramei de clase este de a modela opinia statica a unei aplicatii. Diagramele de clasa sunt singurele diagrame care poate fi mapate direct cu limbaje orientate pe obiect si, astfel, utilizate pe scara larga in momentul de constructie.

Diagramele UML ca diagrama de activitate, diagrama de secventa pot da doar fluxul de ordine al aplicatiei, dar diagrama de clase este un pic diferita. Deci, aceasta este cea mai populara diagrama UML in comunitatea programatorilor.

Deci, scopul diagramei de clase pot fi rezumate astfel:

Analiza si proiectarea reprezentarii statice a unei cereri.

Descrieti responsabilitatile unui sistem.

Componenta de baza 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 multime de proprietati care se iau in considerare in timpul reproducerii schemei, dar aici diagrama va fi considerata dintr-o perspectiva la nivel de top.

Diagrama de clase este de fapt o reprezentare grafica a vederii statice a sistemului si reprezinta aspecte diferite ale aplicatiei. Deci, o colectie de diagrame de clase reprezinta intregul sistem. Ar trebuii sa se tina cont de urmatoarele puncte in timp ce desenati o diagrama de clase:

Numele diagramei de clase ar trebui sa fie semnificativ pentru a descrie aspectul sistemului.

Fiecare element si relatiile lor ar trebui sa fie identificate in prealabil.

Responsabilitatea (atribute si metode) ale fiecarei clase ar trebui sa fie identificate in mod clar.

Pentru fiecare clasa ar trebuii specificat numarul minim de proprietati. Deoarece proprietatile inutile vor face diagrama de complicat.

Utilizati note oricand este necesar pentru a descrie unele aspecte ale diagramei. Deoarece la sfarsitul reprezentarii ar trebui sa fie inteles de catre dezvoltator / programator.

În cele din urma, inainte de a face versiunea finala, diagrama ar trebui sa fie elaborata pe o simpla hartie si revizuita de cate 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 intai de toate, Order si a Customer sunt identificati ca fiind cele doua elemente ale sistemului si au o relatie unu la mai multe, deoarece un client poate avea mai multe comenzi.

Clasa Order este o clasa abstracta si are doua clase (relatia mostenire) si SpecialOrder si NormalOrder.

Cele doua clase au mostenit toate proprietatile ca si clasa Order. În plus, acestea au functii suplimentare, cum ar expediere () si sa primeasca ().

Astfel, urmatoarea diagrama de clase a fost elaborata luand in considerare toate punctele mentionate mai sus:

Unde se utilizeaza diagramele de clase?

Diagrama de clase este o diagrama statica si 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 statica 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 exceptie.

Diagrama de clase arata in mod clar maparea cu limbaje orientate obiect cum ar fi Java, C + +, etc. Deci, din experienta practica diagrama de clase este, in general, utilizata in 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 functionalitatile efectuate de catre sistem.

Construirea de aplicatii software folosind limbaje orientate pe obiect.

Elementele utilizate si notatiile lor sunt urmatoarele:

În reprezentarea clasei atributele si operatiile sunt declarate in compartimentele speciale din dreptunghi, astfel:
- atributele:
numele atributului : tipul atributului = valoare implicita

- operatiile:
numele operatiei (parametri) : tipul valorii returnate

Atunci cand diagrama este folosita pentru a modela structuri de business se pot folosi tipurile de date specifice business-ului, nu programarii, de exemplu: minut, data calendaristica, minut etc.


Mostenirea este o relatie prin care se indica faptul ca o clasa mosteneste caracteristicile clasei parinte. În plus, clasa copil poate avea propriile caracteristici.


Asocierea arata existenta unei relatii intre clase. În exemplul de mai jos, intre Persoana si Autovehicul urmatoarea relatie: o Persoana poate avea zero, unul sau mai multe Autovehicule.


Un tip special de asociere este indicat printr-o clasa de asociere. Altfel spus, relatia in sine este o clasa.
În exemplul de mai jos, relatia dintre Articol si Lista de preturi este de tip mai multi la mai multi: un Articol poate sa apara pe mai multe Liste si o Lista poate avea mai multe Articole. Pe Liste diferite Articolele pot avea preturi diferite.

Dependenta indica faptul ca o clasa depinde de alta clasa, in sensul in care o functie oarecare depinde de un parametru al sau.


Agregarea indica faptul ca o clasa parinte are elemente de tipul clasei copil. În exemplul de mai jos.Tara poate avea mai multe Judete dar, in acelasi timp, un Judet poate exista chiar si in cazul in care clasa Tara nu exista.


Într-o relatie de tip compozitie clasa copil nu poate exista decat daca exista o instanta a clasei parinte. În exemplul de mai jos instanta clasei Comisie exista atata timp cat exista instanta clasei Examen.

Figura 3: O diagrama a claselor pentru un sistem de asigurari.

3.2.1.2 Diagrama obiectelor (Object Diagram)

Acest tip de diagrama este un variant al diagramei claselor care in locul unei clase prezinta mai multe instante ale ei. Diagrama obiectelor foloseste aproape aceleasi notatii ca si diagrama claselor cu doua mici diferente: obiectele sunt scrise subliniat si sunt vizualizate toate instantele relatiei (figura 4).

Desi nu este la fel de importanta ca diagrama claselor, cea o obiectelor este folosita pentru exemplificarea unei diagrame a claselor de complexitate mare, permitand vizualizari ale instantelor actuale si a relatiilor exact asa cum sunt ele realizate. Mai poate fi folosita ca o parte a diagramelor de colaborare, in care sunt vizualizate colaborarile dinamice existente in 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 baza sunt similare pentru diagramele de clase si diagramele obiect. Diagrame obiect reprezinta, 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 si relatiile lor ca o instanta.

Scop:

Scopul unei diagrame ar trebui sa fie inteles in mod clar pentru a putea fi pus in aplicare practic. Scopul diagramelor de obiect este similar cu cel al diagramelor de clase.

Diferenta este ca o diagrama de clase reprezinta un model abstract format din clase si relatiile lor. Dar un obiect diagrama reprezinta o instanta la un moment dat, care este concreta in natura. Aceasta inseamna ca 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.

Relatiile obiectului unui sistem

Vedere statica a unei interactiuni.

Întelegerea comportamentului obiect si relatia lor din punct de vedere practic

Cum se deseneaza diagrama obiect?

Am discutat deja ca o diagrama obiect este o instanta a unei diagrama de clase. Aceasta implica faptul ca un obiect diagrama este format din instante de lucruri utilizate intr-o diagrama de clase.

Deci, ambele diagrame sunt facute din aceleasi elemente de baza, dar in diferite forme. În diagrama de clase sunt elemente intr-o forma abstracta pentru a reprezenta imprimare albastru si in diagrama obiect elementele sunt intr-o forma concreta pentru a reprezenta obiectul in lumea reala.

Pentru a captura un anumit sistem, numarul de diagrame de clase sunt limitate. Dar, daca luam in considerare diagramele obiect, atunci putem avea un numar nelimitat de instante, care sunt unice in natura. Deci, sunt luate in considerare numai acele cazuri care au un impact asupra sistemului.

Din discutia de mai sus este evident ca o singura diagrama obiect nu poate capta toate instantele necesare sau, mai degraba nu poate specifica toate obiectele dintr-un sistem. Deci, solutia este:

În primul rand, o analiza a sistemului si sa se decida care sunt instantele care au date importante si de asociere.

În al doilea rand, se ia in considerare numai acele cazuri care vor acoperi functionalitatea.

În al treilea rand, se fac unele optimizari avand in vedere ca numarul de instante sunt nelimitate.

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

Diagramele obiect sunt formate din obiecte.

Legatura din diagrama de obiect este folosita pentru a conecta obiecte.

Obiectele si link-urile sunt doua elemente folosite pentru a construi o diagrama obiect.

Acum, dupa aceasta, trebuie tinuta seama de urmatoarele lucruri care urmeaza sa fie stabilite inainte de a incepe constructia diagramei:

Diagrama de obiect ar trebui sa aiba un nume semnificativ pentru a indica scopul sau.

Cele mai importante elemente trebuie sa fie identificate.

Asocierea dintre obiecte ar trebui sa fie clarificata.

Valorile unor elemente diferite ar trebui sa fie capturate si apoi incluse in diagrama de obiect.

Adaugarea de note corespunzatoare in punctele in care este necesara mai multa claritate.

Diagrama de mai jos este un exemplu de o diagrama obiect. Ea reprezinta sistemul de management al comenzii pe care le-am discutat in diagrama de clase. Diagrama de mai jos este o instanta a sistemului la un anumit moment de cumparare. Acesta are urmatoarele obiecte

Customer

Order

SpecialOrder

NormalOrder

Acum obiectul Customer (C) este asociat cu trei obiecte de ordine (O1, O2 si O3). Aceste obiecte de ordine sunt asociate cu ordine speciale si obiecte normale de comanda (S1, S2 si N1). Customer are urmatoarele trei ordine cu numere diferite (12, 32 si 40) pentru anumite perioade luate in considerare.

Acum clientul poate creste numarul de Order, in viitor, si in acest scenariu diagrama obiect va reflecta acest lucru. Daca Order, SpecialOrder si NormalOrder sunt observate, atunci vom gasi ca acestea au anumite valori.

Pentru Orders valorile sunt 12, 32, si 40 ceea ce implica faptul ca obiectele sunt cu aceste valori pentru un moment anume (aici, momentul particular de timp in cazul in care achizitia se face este considerat ca fiind momentul), atunci cand instanta este capturata.

Acelasi lucru este si pentru SpecialOrder si NormalOrder, care au numarul de Orders ca 20, 30 si 60. În cazul in care un alt moment de cumparare este considerat, atunci aceste valori se vor schimba in consecinta.

Asadar, urmatoarea diagrama a fost elaborat luand in considerare toate punctele mentionate mai sus:

Unde folosim diagramele obiect?

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

Acum, daca luati un anumit moment din circulatia trenului, veti gasi o imagine statica a acesteia avand urmatoarele:

O situatie speciala, care se executa

Un anumit numar de pasageri. care se va schimba in cazul in care momentul este luat la un alt moment de timp.

Deci, aici ne putem imagina ca momentul de circulatie al trenului este un obiect avand valorile de mai sus. Si acest lucru este valabil pentru orice sistem de viata reala simplu sau complex. Mai pe scurt diagramele obiect sunt utilizate pentru:

Producerea prototipului unui sistem.

Decompilarea.

Modelarea structurilor complexe de date.

Întelegerea sistemului din punct de vedere practic.

Figura 4: O diagrama a claselor si o diagrama a obiectelor (instantele claselor).

3.2.1.3 Diagrama componentelor (Component Diagram)

O diagrama a componentelor prezinta structura fizica a codului in termenii componentelor de cod, realizand o mapare de la view-ul logic la view-ul componentelor. O componenta poate sa contina un cod sursa sau poate sa fie intr-o forma binara sau executabila. În cadrul diagramei vor fi ilustrate si dependentele dintre componente, ceea ce permite o vizualizare simpla a componentelor care vor fi afectate de modificarea uneia dintre ele.

Diagrama componentelor este diferita in ceea ce priveste natura si comportamentul, si este folosita pentru a modela aspectele fizice ale unui sistem. Acum intrebarea este care sunt aceste aspecte fizice? Aspecte fizice sunt elemente cum ar fi executabile, biblioteci, fisiere, documente, etc care isi are resedinta intr-un nod. Deci, diagramele componente sunt folosite pentru a vizualiza organizarea si relatiile dintre componente intr-un sistem. Aceste diagrame sunt, de asemenea, folosite pentru a face crea sisteme executabile.

Scop:

Diagrama Componentelor este un tip special de diagrama in UML. Scopul este, de asemenea, diferit de toate celelalte diagrame discutate pana acum. Ea nu descrie functionalitatea sistemului, dar descrie componentele utilizate pentru a face aceste functionalitati.

Deci, din acest punct de vedere diagrama componentelor este folosita pentru a vizualiza componentele fizice intr-un sistem. Aceste componente sunt biblioteci, pachete, fisiere, etc Diagrama componenta 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 diagrama a componentelor nu poate reprezenta intregul sistem, de aceea se foloseste o colectie de diagrame pentru a reprezenta intregul sistem.

Deci, scopul diagramei componentelor poate fi rezumat astfel:

Vizualizati componentele unui sistem.

Construirea de executabile prin utilizarea de compilare si inversa.

Descrieti organizarea si relatiile 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 in timpul fazei de implementare a unei cereri. Dar este bine pregatita in avans pentru a vizualiza detaliile de implementare.

Initial, sistemul este proiectat folosind diagrame UML diferite si atunci cand artefactele sunt gata diagramele componente sunt folosite pentru a obtine o idee de punere in aplicare.

Aceasta diagrama este foarte importanta, deoarece fara ea cererea nu poate fi pusa in aplicare eficient. O diagrama componenta bine pregatita este, de asemenea, importanta pentru alte aspecte precum performantele de aplicare, intretinere etc.

Deci, inainte de elaborarea unei diagrame a componentelor, trebuie sa identificam in mod clar urmatoarele artefacte:

Fisierele utilizate in sistem.

Bibliotecile si alte obiecte relevante pentru punerea in aplicare.

Relatiile dintre artefacte.

Acum, dupa identificarea artefactelor, trebuie sa urmam urmatoarele puncte:

Utilizati un nume semnificativ pentru a identifica componenta pentru care diagrama va fi construita.

Se pregateste un idee de baza inainte de producerea instrumentelor de ajutor.

Utilizati note pentru a clarifica punctele importante.

Ceea ce urmeaza este o diagrama componenta pentru sistemul managerial de comanda. Aici artefactele sunt fisiere. Deci diagrama prezinta fisierele din aplicatie si relatiile lor. În realitate diagrama de componente contine, de asemenea DLL-uri, biblioteci, foldere, etc

În urmatoarea diagrama patru fisiere sunt identificate si relatiile lor sunt produse. Diagrama de componente nu poate fi compensata in mod direct cu alte diagrame UML discutate pana acum. Deoarece este intocmita in scopuri complet diferite.

Deci diagrama urmatoare de componente a fost elaborata luand in considerare toate punctele mentionate mai sus:

În ce cazuri folosim Diagrama de componente?

Am descris deja ca 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 arata componentele fizice ale unui sistem. Pentru a clarifica aceasta, putem spune ca diagramele de componente descriu organizarea componentelor intr-un sistem.

Organizarea poate fi descrisa in continuare drept locatia componentelor intr-un sistem. Aceste componente sunt organizate intr-un mod special pentru a indeplini cerintele unui sistem. Asa cum am discutat mai inainte, aceste componente sunt biblioteci, fisiere, executabilele etc. Acum, inainte de punerea in aplicare a cererii aceste componente vor fi organizate. Aceasta organizatie componenta este, de asemenea proiectat separat, ca parte a proiectului de executie.

Diagramele de componente sunt foarte importante din punct de vedere al implementarii. Deci, echipa de implementare a unei aplicatii ar trebui sa aiba o cunoastere corecta 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 diagrama a componentelor

3.2.1.4 Diagrama de desfasurare (Deployment View)

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

Figura 9: O diagrama de desfasurare care prezinta structura fizica a sistemului.

Prezentare:

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

Scop:

Numele de "desfasurare" se descrie pe sine in scopul de diagrama. Diagramele de desfasurare sunt utilizate pentru a descrie componentele hardware in care componentele software sunt vizualizate.Aceste diagrame de desfasurare si diagramele componentelor sunt strans legate.

Diagramele Componentelor sunt folosite pentru a descrie componentele si schemele de desfasurare arata modul in care acestea sunt dislocate in hardware. UML este in principal destinat sa se concentreze pe artefactele software ale unui sistem. Dar aceste doua diagrame sunt diagrame de constructii utilizate pentru a se concentra pe componente software si componente hardware.

Deci, cele mai multe diagrame UML sunt utilizate pentru a manipula componente logice, dar diagramele de desfasurare sunt facute ca sa se concentreze asupra topologiei hardware a unui sistem. Diagramele de desfasurare sunt utilizate de catre inginerii de sistem.

Scopul diagramelor de desfasurare 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 desfasurare?

Diagrama de desfasurare reprezinta vizualizarea implementarii unui sistem. Este legata de diagrama de componente, deoarece componentele sunt dislocate cu ajutorul diagramelor de desfasurare. O diagrama de desfasurare/implementare este formata din noduri. Nodurile sunt nimic altceva decat produse hardware fizice utilizate pentru a implementa aplicatia.

Diagrame de implementare sunt utile pentru inginerii de sistem. O diagrama de implementare eficienta este foarte importanta, deoarece controleaza urmatorii parametri

Performanta

Scalabilitate

Mentenabilitatea

Portabilitate

Deci, inainte de elaborarea unei diagrame de implementare ar trebuii identificate urmatoarele:

Noduri

Relatiile intre noduri

Urmatoarea diagrama de desfasurare 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 aplicatie web care este implementata intr-un mediu cluster folosind serverul 1, 2 si serverul 3. Utilizatorul se conecteaza la aplicatie folosind internetul. Traseul se desfasoara de la serverul de caching catre mediul cu clustere.

Deci, urmatoarea diagrama de desfasurare a fost elaborata luand in considerare toate punctele mentionate mai sus:

Unde se folosesc diagramele de desfasurare?

Diagramele de desfasurare sunt folosite in principal de catre inginerii de sistem. Aceste diagrame sunt folosite pentru a descrie componentele fizice (Hardwares), distribuirea si asocierea acestora. Pentru a clarifica acest lucru in detalii, putem vizualiza diagramele de desfasurare ca si componentele hardware / nodurile pe care sunt implementate componente software.

Aplicatiile software sunt dezvoltate pentru a modela procesele complexe legate de afaceri. Doar utilizarea unor aplicatii software eficiente nu sunt suficiente pentru a satisface cerintele unei afaceri. Cerintele de afaceri pot fi descrise in scopul de a sprijini cresterea numarului de utilizatori, timp de raspuns rapid, etc. Pentru a satisface aceste tipuri de componente hardware, cerintele ar trebui sa fie proiectate eficient si intr-un mod rentabil.

Acum, aplicatiile software sunt foarte complexe in natura; pot fi de sine statatoare, bazate pe web, distribuite, bazate pe mainframe si multe altele. Deci, este foarte important sa se proiecteze componentele hardware intr-un mod eficient.

Deci, utilizarea de diagrame de implementare poate fi descrisa dupa cum urmeaza:

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 diagrama din care reiese modul de utilizare a sistemului informatic - modul in care utilizatorii interactioneaza cu acesta (in corespondenta directa cu task-urile acestor utilizatori.). Utilizarea use case diagram nu este absolut necesara pentru a scrie o specificatie cu use case-uri dar este utila pentru a crea o imagine generala 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 intelege comportamentul sistemului atunci cand se executa / opereaza.

Deci, numai comportamentul static nu este suficient pentru a modela un sistem, comportamentul dinamic este mai important decat comportamentul static. În UML exista cinci diagrame disponibile pentru modelul de natura dinamica si diagrama caz de utilizare este unul dintre ele. Acum, ar trebuii sa discutam despre faptul ca diagrama caz de utilizare este dinamica in natura, si ar trebui sa existe anumiti factori interni sau externi pentru efectuarea acestei interactiuni.

Acesti agenti interni si externi sunt cunoscuti drept actori. Deci, diagramele caz de utilizare se compun din actori, cazuri de utilizare si relatiile lor. Diagrama este utilizata pentru a modela sistemul / subsistem unei cereri. O singura diagrama a unui caz de utilizare captureaza o functionalitate speciala a unui sistem.

Deci, pentru a modela intregul 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 aceasta definitie este prea generica pentru a descrie scopul, deoarece alte patru diagrame (activitate, secventa, colaborare si stare) au, de asemenea, acelasi 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 cerintele unui sistem, inclusiv influente interne si externe. Aceste cerinte sunt in general cerintele de proiectare. Deci, atunci cand un sistem este analizat pentru a aduna functionalitatile sale, cazurile de utilizare sunt pregatite si actorii sunt identificati.

Cand sarcina initiala 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, dupa cum urmeaza:

Folosit pentru a aduna cerintele unui sistem.

Folosit pentru a obtine o imagine in afara unui sistem.

Identificarea factorilor externi si interni care influenteaza sistemul.

Arata ca cei care interactioneaza intre cerinte sunt actori.

Cum se elaboreaza diagrama caz de utilizare?

Diagramele caz de utilizare sunt luate in considerare pentru analiza de nivel inalt a unui sistem. Deci, in cazul in care cerintele unui sistem sunt analizate functionalitatile lor sunt capturate in cazurile de utilizare.

Deci, putem spune ca aceste cazuri de utilizare nu sunt altceva decat functionalitatile sistemului scrise intr-un mod organizat. Acum, alte doua lucrurile care sunt relevante pentru cazuri de utilizare sunt actorii. Actori pot fi definiti ca ceva care interactioneaza cu sistemul; pot fi utilizatorii umani, unele aplicatii interne sau poate unele aplicatii externe. Deci, mai pe scurt atunci cand planificam desenarea unei diagrame caz de utilizare trebuie sa tinem cont de urmatoarele elemente identificate.

Functionalitati de a fi reprezentate ca un caz de utilizare

Actori

Relatiile intre cazurile de utilizare si de actori.

Diagramele caz de utilizare sunt trase pentru a captura cerintele functionale ale unui sistem. Astfel, dupa identificarea elementele de mai sus, trebuie sa respectam liniile directoare urmatoare pentru a desena o eficienta diagrama caz de utilizare.

Numele unui caz de utilizare este foarte important. Deci, numele ar trebui sa fie alese in asa fel, astfel incat sa poata identifica functionalitatile efectuate.

Dati un nume potrivit pentru actori.

Afisare relatii si dependentele in mod clar in diagrama.

Nu incercati sa includa toate tipurile de relatii. Deoarece scopul principal al schemei este de a identifica cerintele.

Utilizati nota atunci cand vreodata necesare pentru a clarifica anumite puncte importante.

Ceea ce urmeaza este un exemplu al diagramei use case care reprezinta sistemul de gestionare al comenzilor. Deci, daca ne uitam in diagrama atunci vom gasi trei use case-uri (Order, SpecialOrder si NormalOrder) si un actor, care este clientul.

Use case-urile SpecialOrder si NormalOrder sunt extinse de la case-ul Order , deci au o relatie extinsa.Un alt punct important este de a identifica granitele sistemului, care este prezentat in imagine. Actorul Customer se afla in afara sistemului deoarece acesta este un utilizator extern al sistemului.

Unde folosim diagramele use-case?

Asa cum am discutat deja sunt cinci diagrame in 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 intelege dinamica unui sistem avem nevoie de a utiliza diferite tipuri de diagrame. Diagrama use case este una dintre ele si scopul sau specific este de a aduna cerintele de sistem si actori. Diagramele use case specifica evenimentele unui sistem si fluxurile lor, dar niciodata nu descrie modul in care acestea sunt implementate. Diagrama use case poate fi imaginata ca o cutie neagra in care numai intrarea, iesirea si functia cutiei negre este cunoscuta.

Aceste diagrame sunt utilizate la un nivel foarte ridicat de design, iar acest design de nivel inalt este rafinat din nou si din nou pentru a obtine o imagine completa si practica a sistemului. Un use case bine structurat descrie, de asemenea, conditia pre, post si exceptiile. Si aceste elemente suplimentare sunt folosite pentru a face cazuri de testare atunci cand se efectueaza testarea.

Desi use case-urile nu sunt un bun candidat pentru compilare si decompilare, dar totusi ele sunt folosite intr-un mod usor diferit pentru acestea. Si acelasi lucru este valabil si pentru decompilare. În cazul de compilare diagramele use case se utilizeaza pentru a face cazuri de testare si, in cazurile de decompilare sunt utilizare pentru a pregati detaliile cerintelor de la aplicatia existenta.

Deci, acestea sunt urmatoarele locuri in care diagramele caz de utilizare sunt utilizate:

Cerinta de analiza si proiectare la nivel inalt.

Modelarea cadrului unui sistem.

Decompilarea.

Compilarea..

Elementele utilizate si notatiile lor sunt urmatoarele:

Un exemplu simplu de utilizare a diagramei este urmatorul:



Între actori si use case-uri pot sa existe relatii de generalizare / specializare atunci cand un actor sau un use case poate fi asimilat unei clase de actori, respectiv de use case-uri.



Relatia de tip extensie intre use case-uri
Relatiile de tip extensie (si implicit use case-urile de extensie) se folosesc atunci cand se modeleaza un comportament optional sau exceptional, care nu conditioneaza finalitatea use case-ului de baza. De exemplu, un utilizator poate, in cazuri exceptionale sa aleaga sa depuna o reclamatie dupa efectuarea unei comenzi:


Relatia de tip includere
Relatia de tip includere se foloseste atunci cand use case-ul inclus nu este o parte esentiala a fluxului din use case-ul de baza sau este un comportament care se repeta in mai multe use case-uri. De pilda autentificarea in sistem, desi conditioneaza introducerea unei comenzi, nu este specific introducerii comenzii si de asemenea, poate fi folosit in mai multe use case-uri:

Un caz de utilizare este o descriere a unei functionalitati (o utilizare specifica a sistemului) pe care o ofera sistemul. Diagrama prezinta actorii externi si cazurile de utilizare identificate, numai din punctul de vedere al actorilor (care este comportamentul sistemului, asa cum este el perceput de utilizatorii lui) nu si din interior, precum si conexiunile identificate intre actori si cazurile de utilizare. Un exemplu de diagrama a cazurilor de utilizare este prezentata in figura 2.

Figura 2: O diagrama a cazurilor de utilizare dintr-un sistem de asigurari.

3.2.2.3 Diagrama de activitate (Activity Diagram)

O diagrama de activitate prezinta fluxul secventelor de activitati si este de obicei folosita pentru a descrie activitatile realizate in cadrul unei operatii, folosind daca este cazul decizii si conditii.

Diagrama contine stari de actiune (action states), si mesaje care vor fi trimise sau receptionate ca parte a actiunii realizate.

Diagrama de activitate este o diagrama importanta in UML care descrie aspectele dinamice ale sistemului. Poate fi considerata o diagrama de flux care reprezinta fluxul de control de la o activitate la alta. . Acest flux poate fi secvential, ramificat sau concurent. Diagrama de activitate se refera la toate tipurile de control al fluxului prin utilizarea diferitelor elemente. Activitatea poate fi descrisa ca o operatiune a sistemului.

Scop:

Scopurile de baza 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 afisa fluxul de mesaje de la un obiect la altul, dar diagrama de activitate este utilizata pentru a arata fluxul de mesaje de la o activitate la alta.

Activitatea este o operatiune speciala a sistemului. Diagramele de activitate nu sunt folosite numai pentru vizualizarea dinamica 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 arata nici un flux de mesaje de la o activitate la alta. Diagrama de activitate este uneori considerata ca fiind un grafic de flux, si desi diagrama arata ca un grafic de flux dar nu este. Se prezinta diverse fluxuri cum ar fi ramificat paralel,concurente si singure.

Deci, scopul poate fi descris ca:

Desenati activitatea fluxului unui sistem.

Descrieti secventa de la o activitate la alta.

Descrie fluxul paralel, ramificat si concomitent al sistemului.

Cum se deseneaza diagrama de activitate?

Diagramele de activitate sunt utilizate in principal ca un grafic de flux ce consista din activitati desfasurate de catre sistem. Dar, diagrama de activitate nu este tocmai un grafic de flux, deoarece prezinta anumite capacitati suplimentare. Aceste capacitati suplimentare includ ramificare, flux paralel, swimlane etc

Înainte de intocmirea unei diagrame de activitate trebuie sa avem o intelegere clara cu privire la elementele folosite in diagrama de activitate. Elementul principal al unei diagrame de activitate este activitatea in sine. O activitate este o functie realizata de catre sistem. Dupa identificarea activitatilor avem nevoie sa intelegem modul in care acestea sunt asociate cu constrangeri si conditii.

Deci, inainte de desenarea unei diagrame de activitate, ar trebui sa identificam urmatoarele elemente:

Activitati

Asociatie

Starea

Restrictii

Odata ce parametrii de mai sus sunt identificati avem nevoie pentru a face o imagine mentala a intregului flux. Aceasta imagine mentala este apoi transformata intr-o diagrama de activitate.

Ceea ce urmeaza este un exemplu de diagrama de activitate pentru sistemul de management comanda. În diagrama, patru activitati sunt identificate care sunt asociate cu conditii. Un aspect important ce ar trebui inteles in mod clar este ca o diagrama de activitate nu poate fi compensata exact cu codul. Diagrama de activitate este facuta pentru a intelege fluxul de activitati si, utilizata in principal de catre utilizatorii de afaceri.

Diagrama de mai jos este reprodusa cu patru activitati principale:

Trimite o comanda de catre client

Primeste ordinului de comanda

Confirmare comanda

Expedierea comanda

Dupa primirea cererii sunt efectuate conditia de Order pentru a verifica daca aceasta este SpecialOrder sau NormalOrder. Dupa ce tipul de ordin este identificat, activitatea de expediere este efectuata si acest lucru este marcat de incetarea procesului.

Unde sa utilizati diagrame de activitate?

Utilizarea de baza 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 si descrie fluxul de la un sistem la altul. Acest lucru specific de utilizare nu este disponibil in alte diagrame. Aceste sisteme pot fi de baze de date, cozi de externe sau orice alt sistem.

Acum ne vom uita in aplicatiile practice ale diagramei de activitate. Din discutia de mai sus, este clar ca o diagrama de activitate este trasata de la un nivel foarte ridicat. Deci, va da o vedere de nivel ridicat al unui sistem. Acest punct de vedere la nivel inalt este in principal pentru utilizatorii de afaceri sau orice alta persoana care nu este o persoana tehnica.

Aceasta diagrama este folosita pentru a modela activitatile care nu sunt altceva decat cerintele de afaceri. Deci diagrama are un impact mai mare pe intelegerea de afaceri mai, decat pe detaliile de implementare.

Urmatoarele sunt uzurile principale ale diagramei de activitate:

Modelarea fluxului de lucru prin utilizarea de activitati.

Modelarea cerintelor de business.

Întelegere la nivel inalt a functionalitatilor sistemului.

Investigheaza cerintele de business intr-o etapa ulterioara.

Figura 8: O diagrama de activitate pentru un server de imprimanta.

3.2.2.3 Diagrama de stare (State Diagram)

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

Prezentare:

Trecerea de la o stare la alta este determinata de tranzactiile intermediare - acestea corespund actiunilor pe care le-am intalnit la Activity Diagram ( Statechart Diagram reprezinta 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 in sine clarifica scopul de diagrama si alte detalii. Acesta descrie diferite stari ale unei componente intr-un sistem, aceste stari sunt specifice pentru o componenta / obiectul unui sistem.

O diagrama Statechart descrie o masina de stare. Acum, pentru a clarifica aceasta, masina de stare poate fi definita ca o masina care defineste diferite stari ale unui obiect si aceste stari sunt controlate de evenimente externe sau interne. Diagrama de activitate explicata in capitolul anterior, este un tip special de diagrama Statechart. Deoarece diagrama Statechart defineste 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 dinamica a unui sistem. Ele definesc diferite stari ale unui obiect in timpul vietii sale. Si aceste stari sunt modificate de evenimente. Deci, diagrame Statechart sunt utile si pentru sistemele reactive modelului. Sistemele reactive pot fi definite ca un sistem care raspunde 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 exista si se schimba atunci cand un eveniment este declansat. Deci, scopul cel mai important al diagramei Statechart este de a modela durata de viata 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 stari ale unui obiect in timpul duratei sale de viata.

Definiti o masina de stare pentru a modela starile unui obiect.

Cum se deseneaza diagrama Statechart?

Diagrama este folosita pentru a descrie starile unor diferite obiecte diferite in ciclul lor de viata. Astfel, accentul este pus pe seama modificarilor de stare asupra unor evenimente interne sau externe. Aceste stari de obiecte sunt importante pentru a analiza si a le pune in aplicare cu acuratete. Starile pot fi identificate ca fiind conditia obiectelor atunci cand un anumit eveniment are loc.

Înainte de intocmirea unei diagrame Statechart trebuie sa avem clarificate urmatoarele puncte:

Identifica obiectele importante pentru a fi analizate.

Identifica starile.

Identifica evenimentele.

Urmatorul este un exemplu de diagrama Statechart in cazul in care starea de obiect Order este analizata. Prima stare este o starea de repaus, de unde incepe procesul. Starile urmatoare apar pentru evenimente cum ar fi cerere trimitere, cerere confirmare, si expediere comanda. Aceste evenimente sunt responsabile pentru schimbarile starilor ale unor obiecte.

În timpul ciclului de viata al unui obiect, se trece prin urmatoarele stari si pot exista de asemenea, niste iesiri anormale. Aceste iesiri anormale pot sa apara din cauza unor probleme in sistem. Atunci cand intregul ciclu de viata este complet, este considerat ca tranzactia completa dupa cum se mentioneaza mai jos.

Starea initiala si finala a unui obiect este, de asemenea, prezentata mai jos.

Cand folosim diagrame Statechart?

Din discutia de mai sus putem defini aplicatiile practice ale unei diagrame Statechart. Diagrame Statechart sunt folosite pentru a modela aspectul dinamic al unui sistem ca alte patru diagrame dezafectate in acest tutorial. Dar are unele caracteristici distinctive pentru modelarea natura dinamica.

Diagrama Statechart defineste starile unei componente si modificarile acestei stari sunt dinamice in natura. Deci, scopul sau specific este de a defini schimbarile de stari declansate de evenimente. Evenimentele sunt factori interni sau externi care influenteaza sistemul. Diagramele Statechart sunt utilizate pentru a modela starile si, de asemenea, evenimentele de operare pe sistem. Atunci cand se implementeaza un sistem este foarte important sa se clarifice diferitele stari ale unui obiect in timpul vietii sal, iar diagramele statechart sunt folosite in acest scop. Atunci cand aceste stari si evenimente sunt identificate acestea sunt utilizate pentru a modela si aceste modele sunt folosite in timpul punerii in aplicare a sistemului.

Daca ne uitam la punerea in practica a diagramei Statechart, atunci este folosit in principal pentru a analiza starile obiectului influentat de evenimente. Aceasta analiza este utila pentru a intelege comportamentul sistemului in timpul executiei sale.

Principale uzaje pot fi descrise ca:

Pentru a modela starile obiectului unui sistem.

Pentru a modela un sistem reactiv. Sistemul reactiv consta in obiecte reactive.

Pentru a identifica evenimentele responsabile pentru modificarile de stare.

Compilare si decompilare.

De exemplu o comanda primita de la un client poate fi initial in stare de asteptare, pentru ca un operator sa verifice bonitatea clientului si stocul si sa accepte comanda. Dupa acceptare, se poate produce livrarea produselor comandate si comanda trece in starea de "comanda livrata" dupa care urmeaza facturarea si inchiderea comenzii.

Elementele utilizate si notatiile lor sunt urmatoarele:

În afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie si actiunile 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 gasesc despre Activity Diagram.

Figura5

O stare este de obicei un complement al descrierii unei clase. Asadar, o diagrama de stare prezinta toate starile prin care trece un obiect al clasei precum si evenimentele care-i cauzeaza modificarile de stare. Modificarea starii se numeste tranzitie. Un exemplu de diagrama de stare este prezentat in figura 5.

Nu vom construi diagrame de stare pentru toate clasele din sistem ci numai pentru acelea care au un numar de stari bine definit iar comportamentul clasei este afectat si modificat de acestea.

3.2.2.4 Diagrama de interactiune (Interaction Diagram)

Prezentare:

Din numele de Interactiune, este clar faptul ca diagrama este utilizata pentru a descrie un anumit tip de interactiuni intre diferitele elemente ale modelului. Deci, aceasta interactiune este o parte a comportamentului dinamic al sistemului.Acest comportament interactiv este reprezentata in UML de catre cele doua diagrame cunoscut sub numele de diagrama de secventa si diagrama de colaborare. Scopurile de baza ale ambelor diagrame sunt similare.

Diagrama de secventa pune accent pe secventa de timp a mesajelor si diagrama de colaborare pune accentul pe organizarea structurala a obiectelor care trimit si primesc mesaje.

Scop:

Scopul diagramelor de interactiune este de a vizualiza comportamentul interactiv al sistemului. Acum, vizualizarea interactiunii este o sarcina dificila. Deci, solutia este de a utiliza diferite tipuri de modele pentru a surprinde diferite aspecte ale interactiunii.

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 interactiune pot fi descrie ca fiind:

Pentru a capta comportamentul dinamic al unui sistem.

Pentru a descrie fluxul de mesaje in sistem.

Pentru a descrie organizarea structurala a obiectelor.

Pentru a descrie interactiunea dintre obiecte.

Cum se deseneaza diagrama de interactiune?

Asa cum am discutat deja, scopul diagramelor de interactiune sunt pentru a surprinde aspectul dinamic al unui sistem. Deci, pentru a captura aspectul dinamic avem nevoie sa intelegem ce este un aspect dinamic si modul in care este vizualizat. Aspectul dinamic poate fi definit ca o imagine de moment a sistemului care ruleaza la un moment dat.

Avem doua tipuri de diagrame de interactiune in UML. Una este diagrama de secventa, iar cealalta este o diagrama de colaborare. Diagrama de secventa surprinde secventa de timp a fluxului de mesaj de la un obiect la altul si diagrama de colaborare descrie organizarea de obiecte intr-un sistem care ia parte la un flux de mesaje.

Deci, lucrurile enumerate mai jos sunt identificate in mod clar inainte de desenarea diagramei de interactiune:

Obiecte care iau parte la interactiune.

Fluxurile de mesaje printre obiecte.

Secventa in care mesajele se transmit.

Organizarea obiectului

Voi prezenta in urmatoarele randuri doua diagrame de interactiune pentru modelarea sistemului de management. Prima diagrama este o diagrama secventa, 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 si NormalOrder). Diagrama de mai jos a aratat secventa de mesaje pentru obiectul SpecialOrder si acelasi lucru poate fi utilizat in cazul obiectului NormalOrder. Acum este important sa se inteleaga secventa 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 metoda a obiectului Order. Urmatorul apel este confirm (), care este o metoda a obiectului SpecialOrder si ultima cerere este Dispatch (), care este o metoda a obiectului SpecialOrder. Deci, aici diagrama descrie in principal, metoda de apeluri de la un obiect la altul si acest lucru este, de asemenea, scenariul real atunci cand sistemul este pornit.

Obiectele sunt vazute ca linii verticale distribuite pe orizontala, iar timpul este reprezentat pe axa verticala de sus in jos. Mesajele sunt reprezentate prin sageti intre linile verticale ce corespund obiectelor implicate in mesaj.

Figura 6: Diagrama de secventa pentru un server de imprimanta

3.2.2.4.2 Diagrama de colaborare (Collaboration Diagram)

A doua diagrama de interactiune este diagrama de colaborare.Aceasta prezinta organizarea obiectelor asa cum se arata mai jos. Aici, in diagrama de colaborare, secventa metodei de apel este indicata printr-o tehnica de numerotare dupa cum se arata mai jos. Numarul indica modul in care metodele sunt solicitate una dupa alta. Am luat acelasi sistem de management pentru a descrie diagrama de colaborare.

Cum decidem ce tip de diagrama sa folosim? Daca cel mai important aspect este timpul sau secventa de mesaje vom folosi diagrama de secventa, dar daca trebuie scos in evidenta contextul, vom apela la o diagrama de colaborare.

Metodele solicitate sunt similare cu cea a unei diagrama secventa. Dar diferenta este ca diagrama de secventa nu descrie organizarea obiectelor, in timp ce diagrama de colaborare prezinta organizarea obiectelor.

Acum, pentru a alege intre aceste doua diagrame, accentul principal este dat de tipul de cerinta. În cazul in care secventa de timp este importanta, atunci diagrama de secventa este utilizata si in cazul in care organizarea este necesara, 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 sageti intre obiectele implicate in mesaj si pot fi insotite de etichete care specifica ordinea in care acestea vor fi transmise. De asemenea se pot vizualiza conditii, iteratii, valori returnate, precum si obiectele active care se executa concurent cu alte obiecte active (vezi figura 7).

Figura 7: O diagrama de colaborare pentru un server de imprimanta.

Cand folosim diagramele de interactiune?

Am discutat deja ca diagramele de interactiune sunt folosite pentru a descrie natura dinamica a unui sistem. Acum ne vom uita in scenariile de practica in cazul in care aceste diagrame sunt folosite. Pentru a intelege aplicarea in practica avem nevoie sa intelegem natura de baza a secventei si 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 si a intelege.

Diagramele de secventa sunt utilizate pentru a captura ordinea de mesaje care se transmit de la un obiect la altul. Si diagramele de colaborare sunt folosite pentru a descrie organizarile structurale ale obiectelor care iau parte la interactiune. O singura diagrama nu este suficienta pentru a descrie aspectul dinamic al unui intreg sistem, astfel este folosit un set de diagrame pentru a captura tot sistemul ca un intreg.

Diagramele de interactiune sunt utilizate atunci cand vrem sa intelegem fluxul de mesaje si organizarea structurala. Acum, flux de mesaje inseamna secventa de debit de la un obiect la altul si organizarea structurala inseamna organizarea vizuala a elementelor intr-un sistem.

Acestea sunt urmatoarele intrebuintari ale diagramei de interactiune:

Pentru a modela fluxul de control de catre secventa de timp.

Pentru a modela fluxul de control de catre organizarile structurale.

Pentru compilare.

Pentru decompilare.

4. Concluzii

Cu multi ani in urma, programatorii dezvoltau diverse programe fara o buna analiza si o buna proiectare a respectivelor programe. Avand in vedere ca faza de analiza si proiectare a unui sistem informatic trebuie sa fie gata inainte de realizarea codului, era necesara o atentie marita din partea dezvoltatorilor. Multe dintre aceste etape au fost ignorate in trecut, dar cu timpul dezvoltatorii au inceput sa recunoasca importanta acestor faze, deoarece s-a dovedit ca de acestea depinde producerea de software adecvat si competitiv.

Limbajele de modelare au fost create pentru analiza si 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 toata lumea. UML este foarte popular si folosit deoarece detine o expresivitate foarte buna care ajuta la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau.

UML ofera arhitecturi de sisteme ce functioneaza pe analiza si proiectarea obiectelor cu un limbaj corespunzator pentru specificarea, vizualizarea, construirea si documentarea. 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.

Mai pe scurt, ideea de baza este ca este absolut necesar sa cunoastem principalele elemente ale unui limbaj de modelare inainte de a initia proiectarea si dezvoltarea unui sistem.

5.Bibliografie

https://www.techit.ro/tutorial_uml.php

https://www.scribd.com/doc/46196747/Uml

https://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf

https://www.tutorialspoint.com/uml/uml_component_diagram.htm

Gheorghe Andrei Avram (2002) - Sisteme informationale, Editura Aisteda

MasteringUMLwithRationalRose2002

Wiley - Enterprise Java with UML

Bédard, Y. (1999) - Visual Modeling of Spatial Databases: Towards Spatial PVL and UML, Geomatica, vol. 53, no. 2, pg. 169-186;

Brown, A.W. s.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;

Gheorghies, O., Apetrei, A. (2003) - Ingineria Programarii, Facultatea de Informatica, Universitatea 'Al. I. Cuza', Iasi;

Giurca, A. (2004) - Proiectare in UML, Universitatea din Craiova, Facultatea de Matematica - Informatica;

Ionita, A.D. (2003) - Modelarea UML in ingineria sistemelor de programe, Ed. BIC ALL, Bucuresti, 2003