UNIVERSITAREA „POLITEHNICA” BUCURESTI Facultatea Electronica, Telecomunicatii si Tehnologia Informatiei

Referat Inginerie Software

UML

Berevoianu AdelinaEpure AdrianaTinta 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 desfăşurare (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

1. IntroducereUML (Unified Modelling Language) reprezinta un limbaj vizual de modelare folositor

în domeniul software, dedicat construirii sistemelor complexe si realizarii documentelor de specificaţii, facand referire in mare parte la vizualizarea, specificarea, construirea şi documentarea sistemelor de aplicaţii. Prezinta si limitări cu privire la generarea codului şi reprezinta de asemenea un mijloc bun pentru domeniul ingineriei programării.

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 reuneşte cele mai bune tehnici şi practici din domeniul ingineriei programării, care şi-au dovedit eficienţa î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 proprietăţile 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 colecţie de tehnici de modelare, folosite pentru tratarea multor aspecte ale procesului de concepere şi dezvoltare a software-ului, de la proiectarea BD la interacţiunea modulelor de cod.

Fiecare tehnică de modelare de mai sus dă o vedere diferită, statică sau dinamică, a unei aplicaţii. Colecţia de vederi se numeşte model. Iată unele din tehnicile de modelare UML: diagrame de clase, sau diagrame statice de structură, care modelează entităţile unui sistem prin clase cu atribute şi comportare. Diagramele de clasă descriu, de asemenea, asocierile dintre clase şi constrângerile asupra acestora. Apoi, alte tehnici: diagrame de obiecte, diagrame de "caz de utilizare", diagrame de stare, diagrame de secvenţe, 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 specificaţiei 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 foloseşte 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 încât piesa să fie definită complet. Un cititor avizat al desenului

în epură va şti întotdeauna să refacă mental piesa desenată.

Dacă din cauza complexităţii piesei, cele trei „fotografii” nu sunt suficiente, inginerul va desena şi alte detalii, sau secţiuni ale piesei, dar privite din aceleaşi 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 văzută dintr-un anumit punct de vedere iar modelul complet utilizează toate punctele de vedere relevante.

Aşa cum inginerul proiectant comunică prin desen tehnic, echipei, sau oricărei alte persoane interesate într-un limbai standard, vizual (adică desenul tehnic), făcut să permită descrierea completă dar, in acelaşi timp, scutită de detalii inutile, inginerii software pot comunica cu maximă eficientă Tn limbajul UML.

La fel ca oricare limbai acesta trebuie învăţat şi exersat astfel încât fiecare „cuvânt” să fie înţeles, să ştim unde şi cum se foloseşte, astfel încât să ne putem exprima în „fraze” coerente, care să „spună" exact ceea ce vrem să comunicăm. Limbajul UML ne permite realizarea mai multor figuri, ca nişte fotografii din diverse unghiuri, ale unei realităţi, astfel încât această realitate să fie surprinsă prin toate aspectele ei relevante. In software vom utiliza două puncte de vedere necesare unei descrieri suficiente a realităţii: (1) structural şi (2) comportamental.

În standardul UML sunt definite următoarele 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 UMLPentru 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 utilizând 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 rândul 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 rândul 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, incluzând 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 decât 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 utilizând UML astfel încât 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 definiţie formală a elementului sau un înţeles 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 regăsit în mai multe tipuri de diagrame şi pentru fiecare context există propriile reguli. În figura 1 sunt prezentate câteva 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 dezvoltării şi pentru diverse scopuri.

Există mai multe faze ce trebuie parcurse:■ faza de analiză - surprinde necesităţile sistemului şi modelează clasele de

bază din "lumea reală" şi colaborările dintre acestea; ■ faza de design - se detaliază modelul din faza de analiză şi se formulează o

soluţie tehnică luând î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 desfăşurare - se foloseşte o descriere care explică modul cum va

fi adaptat sistemul arhitecturii fizice concrete.

Analiza unei aplicaţii implică realizarea mai multor categorii de modele, dintre care cele mai importante sunt:

Modelul de utilizare. realizează modelarea problemelor şi a soluţiilor acestora în maniera în care le percepe utilizatorul final al aplicaţiei. Diagramă asociată: diagramă de cazuri de utilizare

Modelul structural: se realizează pe baza analizei statice a problemei şi descrie proprietăţile statice ale entităţilor care compun domeniul problemei. Diagrame asociate: diagramă de module, diagramă de clase

Modelul comportamental: priveşte descrierea funcţionalităţiilor şi a succesiunii în timp a acţiunilor realizate de entităţile domeniului problemei. Diagrame asociate: diagrama (harta) de stări, diagrama de colaborare, diagrama de interacţiune

Principalele părţi ale UML sunt: Vederile (View) - surprind aspecte particulare ale sistemului de modelat. Un view

este o abstractizare a sistemului, iar pentru construirea lui se foloseşte un număr de diagrame.

Diagramele - sunt grafuri care descriu conţinutul unui view. UML are nouă tipuri de

diagrame, care pot fi combinate pentru a forma toate view-urile sistemului. Elementele de modelare - sunt conceptele folosite în diagrame care au corespondenţă

în programarea orientată-obiect, cum ar fi: clase, obiecte, mesaje şi relaţii între acestea: asocierea, dependenţa, generalizarea. Un element de modelare poate fi folosit în mai multe diagrame diferite şi va avea acelaşi înteles şi acelaşi mod de reprezentare.

Mecanismele generale - permit introducerea de comentarii şi alte informaţii 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 informaţiile necesare descrierii sistemului. Un sistem poate fi descris luând în considerare diferite aspecte:

Funcţional: este descrisă structura statică şi comportamentul dinamic al sistemului; Non-funcţional: necesarul de timp pentru dezvoltarea sistemului Din punct de vedere organizatoric: organizarea lucrului, maparea modulelor de cod;

Aşadar pentru descrierea unui sistem sunt necesare un număr de view-uri, fiecare reprezentând o proiecţie a descrierii intregului sistem şi care reflectă un anumuit aspect al sau. Fiecare view este descris folosind un număr de diagrame care conţin informaţii 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

V IEW - UL CAZURILOR DE UTILIZARE (U SE - CASE V IEW ) - Acest view surprinde funcţionalitateasistemului, aşa cum este ea percepută de actorii externi care interacţionează cu sistemul, de exemplu utilizatorii acestuia sau alte sisteme. În componenţa lui intră diagrame ale cazurilor de utilizare şi ocazional, diagrame de activitate. Cei interesaţi de acest view sunt deopotrivă clienţii, designerii, dezvoltatorii dar şi cei care vor realiza testarea şi validarea sistemului.

V IEW - UL LOGIC (L OGIC V IEW ) - Spre deosebire de view-ul cazurilor de utilizare, un view logic"priveşte" înăuntrul sistemului şi descrie atât structura internă a acestuia (clase, obiecte şi relaţii) cât şi colaborările care apar când obiectele trimit unul altuia mesaje pentru a realiza funcţionalitatea 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 interesaţi de acest tip de vizualizare a sistemului sunt designerii şi dezvoltatorii.

V IEW - UL COMPONENTELOR (C OMPONENT V IEW ) - Componentele sunt module de cod dediferite tipuri. În funcţie de conţinutul lor acestea pot fi: componente care conţin cod sursă, componente binare sau excutabile. View-ul componentelor are rolul de a descrie componentele implementate de sistem şi dependenţele ce există între ele, precum şi resursele alocate acestora şi eventual alte informaţii administrative, cum ar fi de exemplu un desfaşurător al muncii de dezvoltare. Este folosit în special de dezvoltatorii sistemului, iar în componenţa sa intră diagrame ale componentelor.

V IEW - UL DE CONCURENŢĂ (C ONCURENT V IEW ) - Sistemul poate fi construit astfel încât să ruleze pe mai multe procesoare. Acest aspect, care este unul nonfuncţional, este util pentru o gestionare eficientă a resurselor, execuţii paralele şi tratări asincrone ale unor evenimente din sistem, precum şi pentru rezolvarea unor probleme legate de comunicarea şi sincronizarea theadu-urilor. Cei care sunt interesaţi 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 desfăşurare).

V IEW - UL DE DESFĂŞURARE (D EPLOYMENT V IEW ) - Desfăşurarea fizică a sistemului, ce calculatoare şi ce device-uri (numite şi noduri) vor fi folosite pentru realizarea efectivă a implementării, 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 desfăşurare. 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 desfăşurare.

3.2 DiagrameÎn UML sunt nouă tipuri de diagrame, care vor fi prezentate pe larg în cele ce

urmează. Diagramele UML pot fi împărţite î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 cepot fi găsite î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 foloseşte 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 instanţe ale ei.

■ Diagrama de stare (State Diagram) - prezintă toate stările prin care trece un obiect al clasei, precum şi evenimentele care-i cauzează modificările de stare.

3. Diagramele comportamentale sunt folosite pentru a vizualiza, specifica, construi şi documenta aspectele dinamice ale unui sistem. Acestea sunt organizate în jurul modalităţilor principale de amodela 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, aşa 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 număr de obiecte, mai precis, secvenţele de mesaje trimise între acestea, pe măsura scurgerii timpului.

■ Diagrama de colaborare (Collaboration Diagram) - surprinde colaborarea dinamică între obiecte, într-o manieră similară cu a diagramei de secvenţă, dar pe lângă schimbul de mesaje (numit şi interacţiune) prezintă obiectele şi relaţiile dintre ele (câteodată referite ca şi context).

■ Diagrama de activitate (Activity Diagram) - prezintă fluxul secvenţelor de activităţi şi este de obicei folosită pentru a descrie activităţile realizate în cadrul unei operaţii, folosind dacă este cazul decizii şi condiţii.

■ Diagrama de tranziţie - se foloseşte pentru a ilustra vederea dinamică a unui sistem. Cum luăm decizia folosirii unui anumit tip de diagramă ? Dacă cel mai important aspect este timpul sau secvenţa 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 săgeţi între obiectele implicate în mesaj şi pot fi însoţite de etichete care specifică ordinea în care acestea vor fi transmise. De asemenea, se pot vizualiza condiţii, iteraţii, 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 încât să ilustreze o anumită parte sau un anumit aspect al sistemului. Un model are de obicei mai multe diagrame de acelaşi 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 funcţie de conţinutul 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/foloseşte o altă clasă), specializate (o clasă este specializarea altei clase) sau împachetate (grupate împreună în cadrul unei unitaţi). Toate

aceste relaţii se materializează în structura internă a claselor în atribute şi operaţii.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 entităţilor sau claselor existente într-un sistem. Acest tip de diagramă este utilizat cel mai adesea de către 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 aplicaţiei software. Ea descrie atributele şi operaţiunile unei clase şi, de asemenea, constrângerile 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, interfeţe, asociaţii, colaborări şi constrângeri. 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 construcţie.

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. Descrieţi responsabilităţile 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 mulţime de proprietăţi 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 următoarele puncte în timp ce desenaţi o diagrama de clase:

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

Fiecare element şi relaţiile 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 numărul minim de proprietăţi. Deoarece proprietăţile inutile vor face diagrama de complicat.

Utilizaţi note oricand este necesar pentru a descrie unele aspecte ale diagramei. Deoarece la sfârşitul reprezentarii ar trebui să fie înţeles de către dezvoltator / programator.

În cele din urmă, înainte de a face versiunea finală, diagrama ar trebui să fie elaborata pe o simpla hârtie şi revizuita de câte 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 întâi de toate, Order şi a Customer sunt identificati ca fiind cele două elemente ale sistemului şi au o relaţie unu la mai multe, deoarece un client poate avea mai multe comenzi.

Clasa Order este o clasă abstractă şi are două clase (relaţia moştenire) şi SpecialOrder si NormalOrder.

Cele două clase au moştenit toate proprietatile ca si clasa Order. În plus, acestea au funcţii suplimentare, cum ar expediere () şi să primească ().

Astfel, urmatoarea diagrama de clase a fost elaborata luând în considerare toate punctele menţionate 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 excepţie.

Diagrama de clase arată în mod clar maparea cu limbaje orientate obiect cum ar fi Java, C + +, etc. Deci, din experienţa 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 funcţionalităţile efectuate de către sistem.

Construirea de aplicatii software folosind limbaje orientate pe obiect.

Elementele utilizate şi notaţiile lor sunt următoarele:

Element Descriere Notaţie

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 operaţiile specifice clasei.

Moştenire

Moştenirea este o relaţie care indică faptul că o clasă moşteneşte caracteristicile unei clase părinte. Sensul săgeţii indică sensul în care se poate spune despre clasa copil că este o<-i>, sau este de tipul<-i> clasă părinte.

Asociere

Asocierea este o relaţie generică între două clase. Aceste relaţii pot fi de tipurile pot defini şi regulile numerice de asociere (unu la unu, unu la mai mulţi, mai mulţi la mai mulţi).

DependenţăAtunci când o clasă depinde de o altă clasă, în sensul că utilizează acea clasă ca şi atribut al său, se foloseşte relaţia de dependenţă.

AgregareAgregarea indică o relaţie de tip întreg-parte (se poate spune despre clasa părinte că are clase de tip copil). În această relaţie, clasa copil poate exista şi fără clasa părinte.

CompoziţieAceastă relaţie derivă din agregare dar se utilizează atunci când o clasă copil nu poate exista decât în cazul existenţei clasei părinte.

În reprezentarea clasei atributele şi operaţiile sunt declarate în compartimentele speciale din dreptunghi, astfel:- atributele: numele atributului : tipul atributului = valoare implicită

- operaţiile:numele operaţiei (parametri) : tipul valorii returnate

Atunci când diagrama este folosită pentru a modela structuri de business se pot folosi tipurile de date specifice business-ului, nu programării, de exemplu: minut, dată calendaristică, minut etc.

Moştenirea este o relaţie prin care se indică faptul că o clasă moşteneşte caracteristicile clasei părinte. În plus, clasa copil poate avea propriile caracteristici.

Asocierea arată existenţa unei relaţii între clase. În exemplul de mai jos, între Persoană şi Autovehicul următoarea relaţie: o Persoană poate avea zero, unul sau mai multe Autovehicule.

Un tip special de asociere este indicat printr-o clasă de asociere. Altfel spus, relaţia în sine este o clasă.În exemplul de mai jos, relaţia dintre Articol şi Lista de preţuri este de tip mai mulţi la mai

mulţi: un Articol poate să apară pe mai multe Liste şi o Listă poate avea mai multe Articole. Pe Liste diferite Articolele pot avea preţuri diferite.

Dependenţa indică faptul că o clasă depinde de altă clasă, în sensul în care o funcţie oarecare depinde de un parametru al său.

Agregarea indică faptul că o clasă părinte are elemente de tipul clasei copil. În exemplul de mai jos.Ţara poate avea mai multe Judeţe dar, în acelaşi timp, un Judeţ poate exista chiar şi în cazul în care clasa Ţara nu există.

Într-o relaţie de tip compoziţie clasa copil nu poate exista decât dacă există o instanţă a clasei părinte. În exemplul de mai jos instanţa clasei Comisie există atâta timp cât există instanţa clasei Examen.

Figura 3: O diagramă a claselor pentru un sistem de asigurări.

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 instanţe ale ei. Diagrama obiectelor foloseşte aproape aceleaşi notaţii ca şi diagrama claselor cu două mici diferenţe: obiectele sunt scrise subliniat şi sunt vizualizate toate instantele relaţiei (figura 4).

Deşi nu este la fel de importantă ca diagrama claselor, cea o obiectelor este folosită pentru exemplificarea unei diagrame a claselor de complexitate mare, permiţând vizualizari ale instanţelor actuale şi a relaţiilor exact aşa cum sunt ele realizate. Mai poate fi folosită ca o parte a diagramelor de colaborare, în care sunt vizualizate colaborările 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 relaţiile lor ca o instanţă.

Scop: Scopul unei diagrame ar trebui să fie înţeles î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 relaţiile 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. Relaţiile obiectului unui sistem

Vedere statica a unei interacţiuni.

Înţelegerea comportamentului obiect şi relaţia 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 instanţe 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, numărul de diagrame de clase sunt limitate. Dar, dacă luăm în considerare diagramele obiect, atunci putem avea un număr nelimitat de instanţe, care sunt unice în natură. Deci, sunt luate în considerare numai acele cazuri care au un impact asupra sistemului.

Din discuţia de mai sus este evident că o singura diagrama obiect nu poate capta toate instanţele necesare sau, mai degrabă nu poate specifica toate obiectele dintr-un sistem. Deci, soluţia este:

În primul rând, o analiză a sistemului şi să se decidă care sunt instanţele care au date importante şi de asociere.

În al doilea rând, se ia în considerare numai acele cazuri care vor acoperi funcţionalitatea.

În al treilea rând, se fac unele optimizari avand in vedere ca numărul de instanţe sunt nelimitate.

Înainte de a se desena diagramele unui obiect, trebuie tinut seama de următoarele 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 construcţia diagramei:

Diagrama de obiect ar trebui să aibă un nume semnificativ pentru a indica scopul său. 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.

Adăugarea de note corespunzătoare î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 cumpărare. Acesta are următoarele 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 următoarele 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 găsi 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 achiziţia se face este considerat ca fiind momentul), atunci când instanţa este capturata.

Acelaşi 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 cumpărare este considerat, atunci aceste valori se vor schimba în consecinţă.

Asadar, urmatoarea diagrama a fost elaborat luând în considerare toate punctele menţionate 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 circulaţia trenului, veţi găsi o imagine statică a acesteia având următoarele:

O situatie speciala, care se execută

Un anumit număr 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 circulaţie al trenului este un obiect având valorile de mai sus. Şi acest lucru este valabil pentru orice sistem de viaţa reală simplu sau complex. Mai pe scurt diagramele obiect sunt utilizate pentru:

Producerea prototipului unui sistem. Decompilarea.

Modelarea structurilor complexe de date.

Înţelegerea sistemului din punct de vedere practic.

Figura 4: O diagramă a claselor şi o diagramă a obiectelor (instanţele claselor).

3.2.1.3 Diagrama componentelor (Component Diagram)

O diagramă a componentelor prezintă structura fizică a codului în termenii componentelor de cod, realizând o mapare de la view-ul logic la view-ul componentelor. O componentă poate să conţină un cod sursă sau poate să fie într-o forma binară sau executabilă. În cadrul diagramei vor fi ilustrate şi dependenţele 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 priveşte 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, fişiere, documente, etc care îşi are reşedinţa într-un nod. Deci, diagramele componente sunt folosite pentru a vizualiza organizarea şi relaţiile 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 până acum. Ea nu descrie funcţionalitatea sistemului, dar descrie componentele utilizate pentru a face aceste funcţionalităţi.

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 colecţie 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.

Descrieţi organizarea şi relaţiile 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 pregătită în avans pentru a vizualiza detaliile de implementare.

Iniţial, sistemul este proiectat folosind diagrame UML diferite şi atunci când artefactele sunt gata diagramele componente sunt folosite pentru a obţine o idee de punere în aplicare.

Această diagramă este foarte importanta, deoarece fără ea cererea nu poate fi pusă în aplicare eficient. O diagramă componentă bine pregătita este, de asemenea, importanta pentru alte aspecte precum performantele de aplicare, întreţinere etc.

Deci, înainte de elaborarea unei diagrame a componentelor, trebuie sa identificam în mod clar următoarele artefacte:

Fişierele utilizate în sistem. Bibliotecile şi alte obiecte relevante pentru punerea în aplicare.

Relaţiile dintre artefacte.

Acum, după identificarea artefactelor, trebuie sa urmam următoarele puncte:

Utilizaţi 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.

Utilizaţi note pentru a clarifica punctele importante.

Ceea ce urmează este o diagrama componentă pentru sistemul managerial de comandă. Aici artefactele sunt fişiere. Deci diagrama prezinta fişierele din aplicatie şi relaţiile lor. În realitate diagrama de componente conţine, de asemenea DLL-uri, biblioteci, foldere, etc

În următoarea diagramă patru fişiere sunt identificate şi relaţiile lor sunt produse. Diagrama de componente nu poate fi compensată în mod direct cu alte diagrame UML discutate până acum. Deoarece este întocmită în scopuri complet diferite.

Deci diagrama următoare de componente a fost elaborata luând în considerare toate punctele menţionate 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 locaţia componentelor într-un sistem. Aceste componente sunt organizate într-un mod special pentru a îndeplini cerinţele unui sistem. Aşa cum am discutat mai inainte, aceste componente sunt biblioteci, fişiere, executabilele etc. Acum, înainte de punerea în aplicare a cererii aceste componente vor fi organizate. Această organizaţie componentă este, de asemenea proiectat separat, ca parte a proiectului de execuţie.

Diagramele de componente sunt foarte importante din punct de vedere al implementarii. Deci, echipa de implementare a unei aplicatii ar trebui să aibă o cunoaştere 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 desfăşurare (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 desfaşurare. Componentele şi obiectele executabile sunt alocate în interiorul nodurilor, ceea ce ne va permite o vizualizare a unitaţilor care se vor executa pe fiecare nod.

Figura 9: O diagramă de desfaşurare care prezintă structura fizică a sistemului.

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

Scop: Numele de „desfăşurare” 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 strâns legate.

Diagramele Componentelor sunt folosite pentru a descrie componentele şi schemele de desfăşurare 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 construcţii 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 desfăşurare sunt făcute ca să se concentreze asupra topologiei hardware a unui sistem. Diagramele de desfăşurare sunt utilizate de către inginerii de sistem.

Scopul diagramelor de desfăşurare 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 desfăşurare? Diagrama de desfăşurare reprezintă vizualizarea implementarii unui sistem. Este legata de diagrama de componente, deoarece componentele sunt dislocate cu ajutorul diagramelor de desfăşurare. O diagramă de desfasurare/implementare este formata din noduri. Nodurile sunt nimic altceva decât 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 următorii parametri

Performanţă Scalabilitate

Mentenabilitatea

Portabilitate

Deci, înainte de elaborarea unei diagrame de implementare ar trebuii identificate următoarele:

Noduri

Relaţiile între noduri

Urmatoarea diagrama de desfăşurare 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 aplicaţie web care este implementata într-un mediu cluster folosind serverul 1, 2 şi serverul 3. Utilizatorul se conecteaza la aplicaţie folosind internetul. Traseul se desfasoara de la serverul de caching catre mediul cu clustere.

Deci, urmatoarea diagrama de desfăşurare a fost elaborata luând în considerare toate punctele menţionate mai sus:

Unde se folosesc diagramele de desfasurare? Diagramele de desfăşurare sunt folosite în principal de către 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 desfăşurare ca şi componentele hardware / nodurile pe care sunt implementate componente software.

Aplicaţiile software sunt dezvoltate pentru a modela procesele complexe legate de afaceri. Doar utilizarea unor aplicaţii software eficiente nu sunt suficiente pentru a satisface cerinţele

unei afaceri. Cerinţele de afaceri pot fi descrise in scopul de a sprijini creşterea numărului de utilizatori, timp de răspuns rapid, etc. Pentru a satisface aceste tipuri de componente hardware, cerinţele ar trebui să fie proiectate eficient şi într-un mod rentabil.

Acum, aplicaţiile 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 interacţionează cu acesta (în corespondenţă directă cu task-urile acestor utilizatori.). Utilizarea use case diagram nu este absolut necesară pentru a scrie o specificaţie 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 înţelege comportamentul sistemului atunci când se execută / opereaza.

Deci, numai comportamentul static nu este suficient pentru a modela un sistem, comportamentul dinamic este mai important decât 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 interacţiuni.

Aceşti agenţi interni şi externi sunt cunoscuti drept actori. Deci, diagramele caz de utilizare se compun din actori, cazuri de utilizare şi relaţiile lor. Diagrama este utilizata pentru a modela

sistemul / subsistem unei cereri. O singura diagrama a unui caz de utilizare capturează o funcţionalitate 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ă definiţie este prea generica pentru a descrie scopul, deoarece alte patru diagrame (activitate, secvenţa, colaborare şi stare) au, de asemenea, acelaşi 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 cerinţele unui sistem, inclusiv influenţe interne şi externe. Aceste cerinţe sunt în general cerinţele de proiectare. Deci, atunci când un sistem este analizat pentru a aduna funcţionalităţile sale, cazurile de utilizare sunt pregătite şi actorii sunt identificati.

Cand sarcina iniţială 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 cerinţele unui sistem. Folosit pentru a obţine o imagine în afara unui sistem.

Identificarea factorilor externi şi interni care influenţează sistemul.

Arată ca cei care interacţionează între cerinţe 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 cerinţele unui sistem sunt analizate funcţionalităţile lor sunt capturate în cazurile de utilizare.

Deci, putem spune că aceste cazuri de utilizare nu sunt altceva decat funcţionalităţile 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 interacţionează cu sistemul; pot fi utilizatorii umani, unele aplicaţii interne sau poate unele aplicaţii externe. Deci, mai pe scurt atunci când planificam desenarea unei diagrame caz de utilizare trebuie să tinem cont de următoarele elemente identificate.

Funcţionalităţi de a fi reprezentate ca un caz de utilizare Actori

Relaţiile între cazurile de utilizare şi de actori.

Diagramele caz de utilizare sunt trase pentru a captura cerinţele funcţionale ale unui sistem. Astfel, după identificarea elementele de mai sus, trebuie să respectam liniile directoare următoare 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 aşa fel, astfel încât să poată identifica funcţionalităţile efectuate.

Daţi un nume potrivit pentru actori.

Afişare relaţii şi dependenţele în mod clar în diagrama.

Nu încercaţi să includă toate tipurile de relatii. Deoarece scopul principal al schemei este de a identifica cerinţele.

Utilizaţi notă atunci când 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 uităm î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 graniţele 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? Aşa 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 înţelege dinamica unui sistem avem nevoie de a utiliza diferite tipuri de diagrame. Diagrama use case este una dintre ele şi scopul său specific este de a aduna cerinţele 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, ieşirea şi funcţia 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 obţine o imagine completă şi practică a sistemului. Un use case bine structurat descrie, de asemenea, conditia pre, post si excepţiile. Şi aceste elemente suplimentare sunt folosite pentru a face cazuri de testare atunci când se efectuează testarea.

Deşi use case-urile nu sunt un bun candidat pentru compilare si decompilare, dar totuşi ele sunt folosite într-un mod usor diferit pentru acestea. Şi acelaşi 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 pregăti detaliile cerinţelor de la aplicatia existentă.

Deci, acestea sunt următoarele locuri în care diagramele caz de utilizare sunt utilizate:

Cerinţa de analiză şi proiectare la nivel înalt. Modelarea cadrului unui sistem.

Decompilarea.

Compilarea..

Elementele utilizate şi notaţiile lor sunt următoarele:

Element Descriere Notaţie

Actor Un actor este, în principiu, un utilizator al sistemului, dar poate fi şi un alt sistem informatic care interacţionează cu sistemul analizat.

Use Case

Use Case-urile se reprezintă sub forma unei elipse în interiorul căreia este scris numele Use Case-ului respectiv.

AsociereAsocierea este utilizată pentru a indica legătura dintre un Actor şi un Use Case, în sensul că acel actor participă într-un fel oarecare în acel Use Case.

Un exemplu simplu de utilizare a diagramei este următorul:

Între actori şi use case-uri pot să existe relaţii de generalizare / specializare atunci când un actor sau un use case poate fi asimilat unei clase de actori, respectiv de use case-uri.

Relaţia de tip extensie între use case-uriRelaţiile de tip extensie (şi implicit use case-urile de extensie) se folosesc atunci când se modelează un comportament opţional sau excepţional, care nu condiţionează finalitatea use case-ului de bază. De exemplu, un utilizator poate, în cazuri excepţionale să aleagă să depună o reclamaţie după efectuarea unei comenzi:

Relaţia de tip includereRelaţia de tip includere se foloseşte atunci când use case-ul inclus nu este o parte esenţială a fluxului din use case-ul de bază sau este un comportament care se repetă în mai multe use case-uri. De pildă autentificarea în sistem, deşi condiţionează 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 funcţionalităţi (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,

aşa 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 asigurări.

3.2.2.3 Diagrama de activitate (Activity Diagram)O diagramă de activitate prezintă fluxul secvenţelor de activitaţi şi este de obicei

folosită pentru a descrie activitaţile realizate în cadrul unei operaţii, folosind dacă este cazul decizii şi condiţii.

Diagrama conţine stări de acţiune (action states), şi mesaje care vor fi trimise sau recepţionate ca parte a acţiunii 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 secvenţial, 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 operaţiune 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 afişa fluxul de mesaje de la un obiect la altul, dar diagrama de activitate este utilizată pentru a arăta fluxul de mesaje de la o activitate la alta.

Activitatea este o operaţiune 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 deşi 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:

Desenaţi activitatea fluxului unui sistem.

Descrieţi secvenţa 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 activităţi desfăşurate de către sistem. Dar, diagrama de activitate nu este tocmai un grafic de flux, deoarece prezinta anumite capacităţi suplimentare. Aceste capacităţi suplimentare includ ramificare, flux paralel, swimlane etc

Înainte de întocmirea unei diagrame de activitate trebuie să avem o înţelegere 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 funcţie realizată de către sistem. După identificarea activităţilor avem nevoie să înţelegem modul în care acestea sunt asociate cu constrângeri şi condiţii.

Deci, înainte de desenarea unei diagrame de activitate, ar trebui să identificam următoarele elemente:

Activităţi Asociaţie

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 activităţi sunt identificate care sunt asociate cu condiţii. Un aspect important ce ar trebui înţeles î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 activităţi şi, utilizata în principal de către utilizatorii de afaceri.

Diagrama de mai jos este reprodusa cu patru activităţi principale:

Trimite o comandă de către client Primeste ordinului de comanda

Confirmare comandă

Expedierea comandă

După primirea cererii sunt efectuate condiţia 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ă utilizaţi 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 aplicaţiile practice ale diagramei de activitate. Din discuţia 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 activităţile care nu sunt altceva decât cerinţele de afaceri. Deci diagrama are un impact mai mare pe înţelegerea de afaceri mai, decat pe detaliile de implementare.

Urmatoarele sunt uzurile principale ale diagramei de activitate:

Modelarea fluxului de lucru prin utilizarea de activităţi. Modelarea cerintelor de business.

Înţelegere la nivel înalt a funcţionalităţilor sistemului.

Investigheaza cerinţele 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 stări 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 stări).

Prezentare:

Trecerea de la o stare la alta este determinată de tranzacţiile intermediare - acestea corespund acţiunilor pe care le-am întâlnit 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 stări ale unei componente într-un sistem, aceste stari sunt specifice pentru o componentă / obiectul unui sistem.

O diagramă Statechart descrie o maşină de stare. Acum, pentru a clarifica aceasta, maşina de stare poate fi definită ca o maşină care defineşte diferite stări 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 defineşte 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 stări ale unui obiect în timpul vieţii 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 răspunde 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 când un eveniment este declanşat. 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 stări ale unui obiect în timpul duratei sale de viaţă.

Definiţi o maşină de stare pentru a modela starile unui obiect.

Cum se deseneaza diagrama Statechart? Diagrama este folosita pentru a descrie stările unor diferite obiecte diferite în ciclul lor de viaţă. Astfel, accentul este pus pe seama modificărilor de stare asupra unor evenimente interne sau externe. Aceste stări de obiecte sunt importante pentru a analiza şi a le pune în aplicare cu acurateţe. Starile pot fi identificate ca fiind conditia obiectelor atunci când un anumit eveniment are loc.

Înainte de întocmirea unei diagrame Statechart trebuie să avem clarificate următoarele puncte:

Identifica obiectele importante pentru a fi analizate. Identifica starile.

Identifica evenimentele.

Următorul 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 următoare 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 următoarele stări şi pot exista de asemenea, niste iesiri anormale. Aceste ieşiri anormale pot să apară din cauza unor probleme în sistem. Atunci cand întregul ciclu de viaţă este complet, este considerat ca tranzacţia completă după cum se menţionează mai jos.

Starea iniţială şi finală a unui obiect este, de asemenea, prezentata mai jos.

Cand folosim diagrame Statechart? Din discuţia de mai sus putem defini aplicaţiile 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 defineşte stările unei componente şi modificările acestei stari sunt dinamice în natură. Deci, scopul său specific este de a defini schimbarile de stari declanşate de evenimente. Evenimentele sunt factori interni sau externi care influenţează sistemul. Diagramele Statechart sunt utilizate pentru a modela starile şi, de asemenea, evenimentele de operare pe sistem. Atunci când se implementeaza un sistem este foarte important să se clarifice diferitele stări ale unui obiect în timpul vieţii sal, iar diagramele statechart sunt folosite în acest scop. Atunci când 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 uităm la punerea în practică a diagramei Statechart, atunci este folosit în principal pentru a analiza starile obiectului influenţat de evenimente. Această analiză este utila pentru a înţelege comportamentul sistemului în timpul execuţiei 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 modificările de stare.

Compilare si decompilare.

De exemplu o comandă primită de la un client poate fi iniţial în stare de aşteptare, 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 notaţiile lor sunt următoarele:

Element Descriere Notaţie

Stare Indică starea în care se găseşte obiectul la un moment dat.

Stare iniţială

Reprezintă punctul de intrare sau punctul în care obiectul este iniţiat. Punctul iniţial este unic.

Stare finală

Reprezintă punctul de final când starea obiectului nu se mai modifică.

Tranziţie Tranziţia reprezintă trecerea de la o stare la alta, provocată de apariţia unui anumit eveniment.

În afara elementelor specifice enumerate mai sus se pot folosi punctele de decizie şi acţiunile 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 găsesc despre Activity Diagram.

Figura5

O stare este de obicei un complement al descrierii unei clase. Asadar, o diagramă de stare prezintă toate stările prin care trece un obiect al clasei precum şi evenimentele care-i

cauzează modificările de stare. Modificarea stării se numeşte tranziţie. 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 număr de stări bine definit iar comportamentul clasei este afectat şi modificat de acestea.

3.2.2.4 Diagrama de interactiune (Interaction Diagram)

Prezentare: Din numele de Interacţiune, este clar faptul că diagrama este utilizata pentru a descrie un anumit tip de interacţiuni între diferitele elemente ale modelului. Deci, această interacţiune este o parte a comportamentului dinamic al sistemului.Acest comportament interactiv este reprezentată în UML de către 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 secvenţa de timp a mesajelor şi diagrama de colaborare pune accentul pe organizarea structurală a obiectelor care trimit şi primesc mesaje.

Scop: Scopul diagramelor de interacţiune este de a vizualiza comportamentul interactiv al sistemului. Acum, vizualizarea interacţiunii este o sarcină dificilă. Deci, soluţia este de a utiliza diferite tipuri de modele pentru a surprinde diferite aspecte ale interacţiunii.

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 interacţiune 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 interacţiunea dintre obiecte.

Cum se deseneaza diagrama de interacţiune? Aşa cum am discutat deja, scopul diagramelor de interacţiune sunt pentru a surprinde aspectul dinamic al unui sistem. Deci, pentru a captura aspectul dinamic avem nevoie să înţelegem 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 interacţiune în UML. Una este diagrama de secvenţă, iar cealalta este o diagrama de colaborare. Diagrama de secvenţă surprinde secvenţa 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 interacţiune:

Obiecte care iau parte la interacţiune. Fluxurile de mesaje printre obiecte.

Secvenţa în care mesajele se transmit.

Organizarea obiectului

Voi prezenta in urmatoarele randuri două diagrame de interacţiune 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 arătat secvenţa de mesaje pentru obiectul SpecialOrder şi acelaşi lucru poate fi utilizat în cazul obiectului NormalOrder. Acum este important să se înţeleagă secvenţa 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. Următorul 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 când sistemul este pornit.

Obiectele sunt văzute ca linii verticale distribuite pe orizontală, iar timpul este reprezentat pe axa verticală de sus în jos. Mesajele sunt reprezentate prin săgeţi î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 aşa cum se arată mai jos. Aici, în diagrama de colaborare, secvenţa metodei de apel este indicată printr-o tehnica de numerotare după cum se arată mai jos. Numărul indică modul în care metodele sunt solicitate una după alta. Am luat acelaşi 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 secvenţa 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 diferenţa 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 secvenţa 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 săgeţi între obiectele implicate în mesaj şi pot fi însoţite de etichete care specifică ordinea în care acestea vor fi transmise. De asemenea se pot vizualiza condiţii, iteraţii, 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 interacţiune? Am discutat deja că diagramele de interacţiune 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 înţelege aplicarea în practică avem nevoie să înţelegem natura de bază a secvenţei ş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 interacţiune. 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 interacţiune sunt utilizate atunci când vrem să înţelegem fluxul de mesaje şi organizarea structurală. Acum, flux de mesaje înseamnă secvenţa de debit de la un obiect la altul şi organizarea structurală înseamnă organizarea vizuala a elementelor într-un sistem.

Acestea sunt următoarele intrebuintari ale diagramei de interacţiune:

Pentru a modela fluxul de control de către secvenţa de timp. Pentru a modela fluxul de control de către organizarile structurale.

Pentru compilare.

Pentru decompilare.

4. ConcluziiCu multi ani in urma, programatorii dezvoltau diverse programe fără 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 atenţie mărită din partea dezvoltatorilor. Multe dintre aceste etape au fost ignorate în trecut, dar cu timpul dezvoltatorii au inceput sa recunoasca importanţa 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 deţine o expresivitate foarte buna care ajută la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau.

UML oferă arhitecturi de sisteme ce funcţionează pe analiza şi proiectarea obiectelor cu un limbaj corespunzător pentru specificarea, vizualizarea, construirea şi documentarea. Notaţiile UML constituie un element esenţial al limbajului pentru realizarea propriu-zisă a modelării şi anume, partea reprezentării grafice pe care se bazează orice limbaj de modelare.

Mai pe scurt, ideea de baza este ca este absolut necesar să cunoaştem principalele elemente ale unui limbaj de modelare înainte de a iniţia 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

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. ş.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 Programării, Facultatea de Informatică, Universitatea "Al. I. Cuza", Iaşi;

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, Bucureşti, 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 desfăşurare (Deployment View)

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