tipuri de diagrame uml. Diagramele UML2 și ER

Diagrama UML este un limbaj de descriere grafică specializat, conceput pentru modelarea obiectelor în dezvoltarea diverselor software. Acest limbaj are un profil larg și este un standard deschis care utilizează diverse notații grafice pentru a crea un model abstract al unui sistem. UML a fost creat pentru a permite definirea, vizualizarea, documentarea și proiectarea tuturor tipurilor de sisteme software. Este de remarcat faptul că diagrama UML în sine nu este un limbaj de programare, dar oferă posibilitatea de a genera un cod separat pe baza acestuia.

De ce este nevoie de ea?

Utilizarea UML nu se termină cu modelarea a tot felul de software. De asemenea, acest limbaj este folosit în mod activ astăzi pentru modelarea diferitelor procese de afaceri, întreținere Ingineria Sistemelor, precum și afișarea structurilor organizatorice.

Cu ajutorul UML, dezvoltatorii de software pot asigura acordul deplin în notația grafică folosită pentru a reprezenta concepte comune precum: componentă, generalizare, clasă, comportament și agregare. Acest lucru realizează un grad mai mare de concentrare pe arhitectură și design.

De asemenea, este de remarcat faptul că există mai multe tipuri de astfel de diagrame.

diagrama de clasă

O diagramă de clasă UML este o diagramă de structură statică concepută pentru a descrie structura unui sistem, precum și pentru a arăta atributele, metodele și dependențele dintre mai multe clase diferite.

Este de remarcat faptul că există mai multe puncte de vedere asupra construcției unor astfel de diagrame, în funcție de modul în care vor fi utilizate:

• Conceptual. În acest caz, diagrama de clasă UML descrie modelul unui domeniu specific și oferă doar clase de obiecte de aplicație.
• Specific. Diagrama este utilizată în procesul de proiectare a diferitelor sisteme informaționale.
• Implementarea. Diagrama de clase include tot felul de clase care sunt utilizate direct în codul programului.

Diagrama componentelor

Diagrama componentelor UML este o diagramă de structură complet statică. Este destinat să demonstreze defalcarea unui anumit sistem software în diferite componente structurale, precum și relațiile dintre acestea. O diagramă a componentelor UML poate folosi tot felul de modele, biblioteci, fișiere, pachete, executabile și multe alte elemente ca atare.

Diagrama structurii compozit/compozit

Diagrama de structură compozită/compozită UML este, de asemenea, o diagramă de structură statică, dar este folosită pentru a arăta structura internă a claselor. Dacă este posibil, această diagramă poate demonstra și interacțiunea elementelor care se află în structura internă a clasei.

O subspecie a acestora este diagrama de colaborare UML, care este folosită pentru a demonstra rolurile și interacțiunile diferitelor clase în cadrul unei colaborări. Sunt destul de utile dacă trebuie să modelați modele de design.

Este de remarcat faptul că diagramele de clasă UML și diagramele de structură compozită pot fi utilizate în același timp.

Diagrama de implementare

Această diagramă este folosită pentru a modela nodurile care rulează, precum și toate tipurile de artefacte care au fost implementate pe ele. În UML 2, artefactele sunt implementate la diferite noduri, în timp ce în prima versiune au fost implementate doar componente. Astfel, diagrama de implementare UML este utilizată în primul rând pentru a doua versiune.

Se formează o dependență de manifestare între un artefact și componenta pe care o implementează.

Diagrama obiectului

Această vizualizare vă permite să vedeți un instantaneu complet sau parțial al sistemului în care este creat anumit moment timp. Afișează complet toate instanțele claselor unui anumit sistem, indicând valorile curente ale parametrilor acestora, precum și relațiile dintre ei.

Diagrama pachetului

Această diagramă este de natură structurală, iar conținutul său principal este tot felul de pachete, precum și relațiile dintre ele. În acest caz, nu există separare greaîntre mai multe diagrame structurale, în urma cărora utilizarea lor se găsește cel mai adesea doar pentru comoditate și nu are nicio semnificație semantică. Este de remarcat faptul că diferite elemente pot furniza alte diagrame UML (exemple: pachetele și diagramele pachetelor în sine).

Utilizarea lor se realizează pentru a asigura organizarea mai multor elemente în grupuri după un anumit atribut, pentru a simplifica structura, precum și pentru a organiza lucrul cu modelul acestui sistem.

diagrama de activitate

Diagrama de activitate UML afișează descompunerea unei anumite activități în mai multe părțile constitutive. În acest caz, conceptul de „activitate” se referă la specificarea unui anumit comportament executabil sub formă de paralel, precum și execuția secvențială coordonată a diverselor elemente subordonate - tipuri imbricate de activități și acțiuni diverse, unite prin fluxuri care merg din ieșirile unui anumit nod către intrările altuia.

Diagrama de activitate UML este adesea folosită pentru a modela diferite procese de afaceri, calcule paralele și secvențiale. Printre altele, modelează tot felul de proceduri tehnologice.

diagrama automată

Această vedere este numită și oarecum diferit - diagrama de stare UML. Are o mașină de stări prezentată cu stări simple și compuse, precum și tranziții.

O mașină de stări este o specificare a unei secvențe de stări diferite prin care trece un anumit obiect sau o interacțiune ca răspuns la unele evenimente din viața sa, precum și răspunsul obiectului la astfel de evenimente. Mașina de stări pe care o folosește diagrama de stări UML este atașată la elementul original și utilizată pentru a defini comportamentul instanțelor sale.

Așa-numitele diagrame dragon pot fi folosite ca analogi ale unor astfel de diagrame.

Diagrame de caz de utilizare

Diagrama de caz de utilizare UML afișează toate relațiile care apar între actori, precum și diferitele cazuri de utilizare. Sarcina sa principală este de a oferi un mijloc cu drepturi depline prin care clientul, utilizatorul final sau un dezvoltator poate discuta în comun despre comportamentul și funcționalitatea unui anumit sistem.

Dacă o diagramă de caz de utilizare UML este utilizată într-un proces de modelare a sistemului, atunci analistul va:

• Separați clar sistemul care se modelează de mediul său.
• Identificați actorii, modalitățile de interacțiune a acestora cu acest sistem, precum și funcționalitatea așteptată a acestuia.
• Setați în glosar ca domeniu de subiect diverse concepte, care sunt legate de descriere detaliata funcționalitatea acestui sistem.

Dacă o diagramă de utilizare este în curs de dezvoltare în UML, procedura începe cu o descriere textuală, care se obține atunci când se lucrează cu clientul. În același timp, merită remarcat faptul că diferite cerințe nefuncționale sunt complet omise în procesul de compilare a modelului de caz de utilizare, iar un document separat va fi deja format pentru ele.

Comunicatii

Diagrama de comunicare, la fel ca diagrama secvență UML, este tranzitivă, adică exprimă interacțiunea, dar în același timp o demonstrează în moduri diferite, iar dacă este necesar, cu gradul de acuratețe necesar, se poate transforma în o alta.

Diagrama de comunicare reflectă interacțiunile care apar între diferitele elemente ale structurii compozite, precum și rolurile cooperării. Principala sa diferență față de diagrama de secvență este că indică în mod clar relația dintre mai multe elemente, iar timpul nu este folosit ca dimensiune separată.

Acest tip se distinge printr-un format absolut liber de ordonare a mai multor obiecte și relații în același mod în care se face într-o diagramă de obiecte. Dacă este necesar să se mențină ordinea mesajelor în acest format liber, acestea sunt numerotate cronologic. Citirea acestei diagrame începe cu mesajul inițial 1.0, iar ulterior continuă în direcția în care mesajele sunt transmise de la un obiect la altul.

În cea mai mare parte, astfel de diagrame arată exact aceleași informații pe care ni le oferă o diagramă de secvență, dar pentru că folosește un mod diferit de prezentare a informațiilor, anumite lucruri dintr-o diagramă devin mult mai ușor de determinat decât în ​​alta. De asemenea, este de remarcat faptul că o diagramă de comunicare arată mai clar cu ce elemente interacționează fiecare element individual, în timp ce o diagramă de secvență arată mai clar în ce ordine sunt desfășurate interacțiunile.

Diagrama secvenței

Diagrama secvenței UML arată interacțiunile dintre mai multe obiecte, care sunt ordonate în funcție de momentul apariției lor. O astfel de diagramă arată o interacțiune ordonată în timp între mai multe obiecte. În special, afișează toate obiectele care participă la interacțiune, precum și secvența completă de mesaje schimbate de acestea.

Elementele principale în acest caz sunt desemnările diferitelor obiecte, precum și liniile verticale care afișează trecerea timpului și dreptunghiurile care reprezintă activitatea unui anumit obiect sau îndeplinirea unei anumite funcții de către acesta.

Diagrama de cooperare

Acest tip de diagramă vă permite să afișați interacțiunile dintre mai multe obiecte, făcând abstracție din secvența traducerii mesajului. Acest tip de diagrame într-o formă compactă afișează absolut toate mesajele transmise și primite ale unui anumit obiect, precum și formatele acestor mesaje.

Deoarece diagramele de secvență și diagramele de comunicare sunt pur și simplu vederi diferite ale acelorași proceduri, Rational Rose oferă posibilitatea de a crea o diagramă de secvență de comunicare dintr-o diagramă de secvență sau invers și, de asemenea, le sincronizează complet automat.

Diagrame de prezentare a interacțiunii

Acestea sunt diagrame UML, care aparțin unui tip de diagrame de activitate și includ atât elemente de secvență, cât și constructe de flux de control.

Este de remarcat faptul că formatul dat combină diagrama de colaborare și secvență, care oferă capacitatea de a puncte diferite pentru a lua în considerare interacțiunea dintre mai multe obiecte din sistemul care se formează.

Diagramă de timp

Reprezintă o versiune alternativă a diagramei secvențe, care demonstrează în mod explicit schimbarea stării pe linia de viață cu o anumită scară de timp. Poate fi destul de util în diverse aplicații în timp real.

Care sunt beneficiile?

Este de remarcat câteva avantaje care disting diagrama de utilizare UML și altele:

• Limbajul este orientat pe obiecte, drept urmare tehnologiile de descriere a rezultatelor analizei și proiectării efectuate sunt apropiate semantic de metodele de programare în tot felul de limbaje orientate pe obiecte de tip modern.
• Cu ajutor limba dată sistemul poate fi descris din aproape orice punct de vedere posibil, iar diferite aspecte ale comportamentului său sunt descrise în același mod.
• Toate diagramele sunt relativ ușor de citit chiar și după o familiarizare relativ rapidă cu sintaxa acesteia.
• UML vă permite să vă extindeți, precum și să introduceți propriile stereotipuri grafice și text, ceea ce contribuie la utilizarea acestuia nu numai în ingineria software.
• Limba a devenit destul de răspândită și, de asemenea, se dezvoltă destul de activ.

Defecte

În ciuda faptului că construcția diagramelor UML are multe dintre avantajele sale, acestea sunt adesea criticate pentru următoarele neajunsuri:

• redundanţă. În marea majoritate a cazurilor, criticii spun că UML-ul este prea mare și complex și de multe ori acest lucru este nejustificat. Include destul de multe construcții și diagrame redundante sau aproape inutile și, de cele mai multe ori, astfel de critici se îndreaptă către a doua versiune, și nu prima, deoarece în revizuirile mai noi există mai multe compromisuri „proiectate de comitet”.
• Diverse inexactități în semantică. Deoarece UML este definit printr-o combinație între el însuși, engleză și OCL, îi lipsește rigiditatea care este inerentă limbilor care sunt definite cu precizie de tehnicile de descriere formală. În anumite situații, sintaxa abstractă a OCL, UML și engleză încep să se contrazică, în timp ce în alte cazuri sunt incomplete. Inexactitatea descrierii limbajului în sine afectează atât utilizatorii, cât și furnizorii de instrumente, ducând în cele din urmă la incompatibilități de instrumente din cauza modului unic de tratare a diferitelor specificații.
• Probleme în procesul de implementare și studiu. Toate problemele de mai sus creează anumite dificultăți în procesul de implementare și învățare a UML, iar acest lucru este valabil mai ales atunci când managementul îi obligă pe ingineri să-l folosească atunci când le lipsesc abilitățile anterioare.
• Codul reflectă codul. O altă părere este că nu modelele frumoase și atractive sunt importante, ci sistemele care funcționează direct, adică codul este proiectul. În conformitate cu această viziune, este necesar să se dezvolte mai mult metoda eficienta software de scriere. UML este apreciat în abordările care compilează modele pentru a regenera un posibil sau cod sursa. Dar, în realitate, acest lucru poate să nu fie suficient, deoarece limbajului îi lipsesc proprietățile de completitudine Turing și fiecare cod generat va fi în cele din urmă limitat de ceea ce instrumentul de interpretare UML poate presupune sau determina.
• Nepotrivire de încărcare. Acest termen provine din teoria analizei sistemelor pentru a determina incapacitatea intrării unui anumit sistem de a percepe rezultatul altuia. Ca în oricare sisteme standard notație, UML poate reprezenta unele sisteme într-un mod mai eficient și mai concis decât altele. Astfel, dezvoltatorul este mai înclinat către acele soluții care sunt mai confortabile pentru a țese toate punctele forte ale UML-ului, precum și ale altor limbaje de programare. Această problemă este mai evident dacă limbajul de dezvoltare nu respectă principiile de bază ale doctrinei ortodoxe orientate pe obiecte, adică nu încearcă să funcționeze în conformitate cu principiile OOP.
• Încearcă să fie universal. UML este un limbaj de modelare scop general, care încearcă să asigure compatibilitatea cu orice limbaj de procesare care există astăzi. În contextul unui anumit proiect, pentru ca echipa de proiectare să atingă scopul final, este necesar să se aleagă caracteristicile aplicabile ale acestui limbaj. În plus, posibilele modalități de limitare a sferei de utilizare a UML în orice domeniu anume trec printr-un formalism care nu este pe deplin formulat, dar care în sine este obiectul criticii.

Astfel, utilizarea acestui limbaj nu este relevantă în toate situațiile.

UML este un limbaj unificat de modelare grafică pentru descrierea, vizualizarea, proiectarea și documentarea sistemelor OO. UML este conceput pentru a sprijini procesul de modelare PS bazat pe abordarea OO, pentru a organiza relația dintre conceptele conceptuale și de program și pentru a reflecta problemele de scalare a sistemelor complexe. Modelele UML sunt utilizate în toate etapele ciclului de viață al software-ului, de la analiza afacerii până la întreținerea sistemului. Diferite organizații pot utiliza UML-ul în felul lor, în funcție de zonele lor problematice și de tehnologiile utilizate.

O scurtă istorie a UML

Până la mijlocul anilor 1990, câteva zeci de metode de modelare OO au fost propuse de diverși autori, fiecare dintre acestea folosind propria sa notație grafică. În același timp, oricare dintre aceste metode avea punctele sale forte, dar nu permitea construirea unui model PS suficient de complet, pentru a-l arăta „din toate părțile”, adică toate proiecțiile necesare (vezi articolul 1). În plus, absența unui standard de modelare OO a îngreunat pentru dezvoltatori alegerea celei mai potrivite metode, ceea ce a împiedicat utilizarea pe scară largă a unei abordări OO pentru dezvoltarea software.

La solicitarea Object Management Group (OMG) - o organizație responsabilă cu adoptarea standardelor în domeniul tehnologiilor obiectelor și bazelor de date, problema urgentă a unificării și standardizării a fost rezolvată de autorii celor mai populare trei metode OO - G. Booch , D. Rambo și A. Jacobson, care au combinat eforturile, au creat UML versiunea 1.1, aprobată de OMG în 1997 ca standard.

UML este un limbaj

Orice limbă constă dintr-un dicționar și reguli pentru combinarea cuvintelor pentru a face construcții semnificative. Deci, în special, sunt aranjate limbaje de programare, cum ar fi UML. Caracteristica sa distinctivă este că vocabularul limbii este format din elemente grafice. Fiecare simbol grafic corespunde unei semantici specifice, astfel încât un model creat de un dezvoltator poate fi înțeles fără ambiguitate de către altul și, de asemenea, instrument software interpretarea UML. Din aceasta, în special, rezultă că un model PS prezentat în UML poate fi tradus automat într-un limbaj de programare OO (cum ar fi Java, C++, VisualBasic), adică cu un instrument de modelare vizuală bun care acceptă UML, prin construind un model, vom primi și un blank codul programului corespunzătoare acestui model.

Trebuie subliniat că UML este un limbaj, nu o metodă. Acesta explică din ce elemente să creeze modele și cum să le citească, dar nu spune nimic despre ce modele și în ce cazuri ar trebui dezvoltate. Pentru a crea o metodă bazată pe UML, este necesar să o completați cu o descriere a procesului de dezvoltare PS. Un exemplu de astfel de proces este Procesul Rațional Unificat, care va fi discutat în articolele ulterioare.

Vocabularul UML

Modelul este reprezentat sub formă de entități și relații dintre ele, care sunt prezentate pe diagrame.

Esențe sunt abstractizări care sunt elementele principale ale modelelor. Există patru tipuri de entități - structurale (clasă, interfață, componentă, caz de utilizare, cooperare, nod), comportamentale (interacțiune, stare), grupare (pachete) și adnotative (comentarii). Fiecare tip de entitate are propria sa reprezentare grafică. Entitățile vor fi discutate în detaliu atunci când se studiază diagramele.

Relaţii arată relații diferite între entități. Următoarele tipuri de relații sunt definite în UML:

• Dependenta arată o astfel de relație între două entități, când o modificare a uneia dintre ele - independentă - poate afecta semantica celeilalte - dependente. O dependență este reprezentată de o săgeată punctată care indică de la entitatea dependentă la entitatea independentă.
• Asociere este o relație structurală care arată că obiectele unei entități sunt legate de obiectele alteia. Grafic, o asociere este prezentată ca o linie care conectează entitățile aferente. Asociațiile sunt folosite pentru a naviga între obiecte. De exemplu, asocierea dintre clasele „Comandă” și „Produs” poate fi folosită pentru a găsi toate produsele specificate într-o anumită comandă - pe de o parte, sau pentru a găsi toate comenzile care conțin acest produs - pe de altă parte. Este clar că programele corespunzătoare trebuie să implementeze un mecanism care să asigure o astfel de navigare. Dacă navigarea este necesară într-o singură direcție, aceasta este indicată printr-o săgeată la sfârșitul asocierii. Un caz special de asociere este agregarea - o relație de forma „întreg” – „parte”. Grafic, se evidențiază cu un romb la capăt lângă entitate-întreg.
• Generalizare este o relație între o entitate-mamă și o entitate copil. În esență, această relație reflectă proprietatea moștenirii pentru clase și obiecte. Generalizarea este prezentată ca o linie care se termină cu un triunghi îndreptat către entitatea părinte. Copilul moștenește structura (atributele) și comportamentul (metodele) părintelui, dar în același timp poate avea noi elemente de structură și noi metode. UML permite moștenirea multiplă atunci când o entitate este legată de mai multe entități părinte.
• Implementarea- relatia dintre entitatea care defineste specificarea comportamentului (interfata) cu entitatea care defineste implementarea acestui comportament (clasa, componenta). Această relație este folosită în mod obișnuit în modelarea componentelor și va fi descrisă mai detaliat în articolele ulterioare.

Diagrame. UML oferă următoarele diagrame:

• Diagrame care descriu comportamentul sistemului:
• Diagrame de stare (diagrame de stare),
• Diagrame de activitate,
• Diagrame de obiecte,
• Diagrame secvențe,
• Diagrame de colaborare;
• Diagrame care descriu implementarea fizică a sistemului:
• Diagrame componente;
• Diagrame de implementare.

Vedere de control al modelului. Pachete.

Am spus deja că pentru ca un model să fie bine înțeles de către o persoană, este necesar să-l organizăm ierarhic, lăsând un număr mic de entități la fiecare nivel al ierarhiei. UML include un mijloc de organizare a unei reprezentări ierarhice a unui model - pachete. Orice model constă dintr-un set de pachete care pot conține clase, cazuri de utilizare și alte entități și diagrame. Un pachet poate include alte pachete, ceea ce vă permite să creați ierarhii. UML nu furnizează diagrame de pachete separate, dar acestea pot apărea în alte diagrame. Pachetul este afișat ca dreptunghi cu o filă.

Ce oferă UML.

• descrierea ierarhică a unui sistem complex prin evidențierea pachetelor;
• formalizarea cerințelor funcționale pentru sistem folosind aparatul de cazuri de utilizare;
• detalierea cerințelor pentru sistem prin construirea de diagrame de activități și scenarii;
• selectarea claselor de date și construirea unui model conceptual de date sub formă de diagrame de clase;
• selecția claselor care descriu interfața cu utilizatorulși crearea unei scheme de navigare pe ecran;
• descrierea proceselor de interacțiune a obiectelor în îndeplinirea funcțiilor sistemului;
• descrierea comportamentului obiectelor sub formă de diagrame de activități și stări;
• descrierea componentelor software și interacțiunea acestora prin interfețe;
• descrierea arhitecturii fizice a sistemului.

Și ultimul…

În ciuda tuturor atractivității UML, ar fi dificil să-l folosești în modelarea PS reală fără instrumente de modelare vizuală. Astfel de instrumente vă permit să prezentați rapid diagrame pe ecranul de afișare, să le documentați, să generați spații libere de coduri de program în diferite limbaje de programare OO și să creați scheme de baze de date. Cele mai multe dintre ele includ posibilitatea de reinginerire a codurilor de program - restabilirea anumitor proiecții ale modelului PS prin analiza automată a codurilor sursă ale programelor, ceea ce este foarte important pentru a se asigura că modelul și codurile se potrivesc și atunci când se proiectează sisteme care moștenesc funcționalitatea sistemelor predecesoare. .

Toate diagramele UML pot fi împărțite condiționat în două grupuri, primul fiind diagramele generale. Diagramele generale sunt practic independente de subiectul modelării și pot fi utilizate în orice proiect software fără a ține cont de domeniul de subiect, zona de decizie etc.

1.5.1. Diagrama de utilizare

Diagrama de utilizare(diagrama cazului de utilizare) este cea mai generală reprezentare a scopului funcțional al sistemului.

Diagrama de utilizare este menită să răspundă la întrebarea principală de modelare: ce face sistemul în lumea exterioară?

În diagrama de utilizare sunt utilizate două tipuri de entități principale: cazurile de utilizare 1 și actorii 2, între care se stabilesc următoarele tipuri principale de relații:

• asocierea dintre actor și cazul de utilizare 3 ;
• generalizarea între actori 4 ;
• generalizare între cazuri de utilizare 5 ;
• dependențe (de diverse tipuri) între cazuri de utilizare 6 .

O diagramă de utilizare, ca oricare alta, poate avea comentarii 7 . Mai mult, este recomandat să faceți acest lucru pentru a îmbunătăți lizibilitatea diagramelor.

Elementele principale ale notației utilizate în diagrama de utilizare sunt prezentate mai jos. Descriere detaliata prezentate în secțiunea 2.2.

1.5.2. diagrama de clasă

diagrama de clasă(diagrama de clasă) este modalitatea principală de a descrie structura sistemului.

Acest lucru nu este surprinzător, deoarece UML este în primul rând un limbaj orientat pe obiecte, iar clasele sunt blocul de construcție principal (dacă nu singurul).

Pe diagrama de clase se utilizează un tip principal de entități: clasele 1 (inclusiv numeroase cazuri speciale de clase: interfețe, tipuri primitive, clase de asociere și multe altele), între care se stabilesc următoarele tipuri principale de relații:

• asociere între clasele 2 (cu multe detalii suplimentare);
• generalizare între clasele 3 ;
• dependențe (de diverse tipuri) între clasele 4 și între clase și interfețe.

Unele elemente ale notației utilizate în diagrama de clase sunt prezentate mai jos. O descriere detaliată este dată în capitolul 3 .

1.5.3. diagrama automată

diagrama automată(diagrama mașinii de stări) este una dintre modalitățile de a descrie comportamentul în detaliu în UML pe baza alocării explicite a stărilor și a descrierii tranzițiilor între stări.

În esență, diagramele automate, așa cum sugerează și numele, sunt un grafic de tranziție de stare (vezi capitolul 4), încărcat cu multe detalii și detalii suplimentare.

În diagrama automată, se utilizează un tip principal de entități - stările 1 și un tip de relații - tranzițiile 2, dar pentru ambele sunt definite o mulțime de soiuri, cazuri speciale și denumiri suplimentare. A le enumera pe toate într-o recenzie introductivă nu are sens.

O descriere detaliată a tuturor variațiilor diagramelor automate este dată în secțiunea 4.2, iar figura următoare prezintă doar elementele principale ale notației utilizate în diagrama automată.

1.5.4. diagrama de activitate

diagrama de activitate(diagrama activității) - o modalitate de a descrie comportamentul bazat pe indicarea fluxurilor de control și a fluxurilor de date.

O diagramă de activitate este un alt mod de a descrie comportamentul care seamănă vizual cu o diagramă bună veche. Cu toate acestea, datorită notației modernizate, în concordanță cu abordarea orientată pe obiect, și cel mai important, datorită noii componente semantice (interpretarea liberă a rețelelor Petri), diagrama de activitate UML este un instrument puternic de descriere a comportamentului sistemului.

În diagrama de activitate, se utilizează un tip principal de entități - acțiunea 1 și un tip de relație - tranzițiile 2 (transferuri de control și date). De asemenea, sunt folosite construcții precum furcile, fuziunile, conexiunile, ramurile 3 , care sunt asemănătoare entităților, dar nu sunt chiar așa, ci reprezintă o modalitate grafică de a descrie unele cazuri speciale de relații multi-loc. Semantica elementelor diagramei de activitate este discutată în detaliu în Capitolul 4. Elementele principale ale notației utilizate în diagrama de activități sunt prezentate mai jos.

1.5.5. Diagrama secvenței

Diagrama secvenței(diagrama secvenței) este o modalitate de descriere a comportamentului sistemului pe baza indicației secvenței mesajelor transmise.

De fapt, o diagramă de secvență este o înregistrare a protocolului unei anumite sesiuni a sistemului (sau un fragment al unui astfel de protocol). În programarea orientată pe obiecte, cel mai esențial lucru în timpul execuției este transmiterea de mesaje între obiectele cooperante. Este secvența de trimitere a mesajelor care este afișată pe această diagramă, de unde și numele.

În diagrama de secvență, se folosește un tip principal de entități - instanțe ale clasificatoarelor care interacționează 1 (în principal clase, componente și actori) și un tip de relație - conexiuni 2 prin care se fac schimb de mesaje 3 . Există mai multe moduri de a trimite mesaje, care în notație grafică diferă sub forma unei săgeți corespunzătoare unei relații.

Un aspect important al diagramei secvențe este afișarea explicită a trecerii timpului. Spre deosebire de alte tipuri de diagrame, cu excepția poate diagramelor de sincronizare, într-o diagramă de secvență este importantă nu doar prezența legăturilor grafice între elemente, ci și poziția relativă a elementelor pe diagramă. Și anume, se consideră că există o axă a timpului (invizibilă), implicit direcționată de sus în jos, iar mesajul care este trimis ulterior este desenat mai jos.

Axa timpului poate fi direcționată orizontal, caz în care se consideră că timpul curge de la stânga la dreapta.

Figura următoare prezintă principalele elemente ale notației utilizate într-o diagramă de secvență. Pentru a desemna obiectele care interacționează în sine, se folosește notația standard - un dreptunghi cu numele unei instanțe de clasificator. Linia punctată care iese din el se numește linia vieții (linia vieții) 4 . Aceasta nu este o desemnare a unei relații în model, ci un comentariu grafic menit să îndrepte cititorul diagramei în direcția corectă. Figurile sub formă de benzi înguste suprapuse pe linia vieții nu sunt, de asemenea, imagini ale entităților simulate. Acesta este un comentariu grafic care arată durata de timp în care un obiect deține o apariție de execuție 5 sau, cu alte cuvinte, are loc o activare a unui obiect. Etapele de interacțiune compuse (fragment combinat) 6 permit diagramei de secvență să reflecte aspectele algoritmice ale protocolului de interacțiune. Consultați Capitolul 4 pentru mai multe detalii despre notarea diagramei secvențe.

1.5.6. Diagrama de comunicare

Diagrama de comunicare(diagrama de comunicare) - un mod de a descrie comportamentul, echivalent semantic cu o diagramă de secvență.

De fapt, aceasta este aceeași descriere a secvenței de schimb de mesaje a instanțelor care interacționează ale clasificatorilor, exprimată doar prin alte mijloace grafice. Mai mult, majoritatea instrumentelor pot converti automat diagramele secvențe în diagrame de comunicare și invers.

Astfel, în diagrama de comunicare, precum și în diagrama de secvență, se utilizează un tip principal de entități - instanțe de clasificatori interacționați 1 și un tip de relație - conexiuni 2 . Totuși, aici accentul nu este pus pe timp, ci pe structura relațiilor dintre instanțe specifice.

În figura sunt prezentate principalele elemente ale notației utilizate în diagrama de comunicare. Pentru a desemna obiectele care interacționează în sine, se folosește notația standard - un dreptunghi cu numele unei instanțe de clasificator. Poziția reciprocă a elementelor pe diagrama cooperării nu contează - importante sunt doar conexiunile (cel mai adesea instanțe de asociere), de-a lungul cărora se transmit mesaje 3 . Pentru a afișa ordinea în timp a mesajelor, se utilizează numerotarea zecimală ierarhică.

1.5.7. Diagrama componentelor

Diagrama componentelor(diagrama componentelor) - arată relația dintre modulele (logice sau fizice) care alcătuiesc sistemul simulat.

Principalul tip de entități din diagrama componentelor sunt componentele în sine 1 , precum și interfețele 2 , prin care este indicată relația dintre componente. În diagrama componentelor se aplică următoarele relații:

• implementari intre componente si interfete (componenta implementeaza interfata);
• dependențe între componente și interfețe (o componentă folosește o interfață) 3 .

Figura prezintă principalele elemente ale notației utilizate în diagrama componentelor. O descriere detaliată este dată în capitolul 3 .

1.5.8. Diagrama de amplasare

Diagrama de amplasare(diagrama de implementare), împreună cu afișarea compoziției și relațiilor elementelor sistemului, arată modul în care acestea sunt localizate fizic pe resursele de calcul în timpul execuției.

Astfel, în diagrama de plasare, în comparație cu diagrama componentelor, se adaugă două tipuri de entități: artefactul 1 , care este implementarea componentei 2 și a nodului 3 (poate fi fie un clasificator care descrie tipul de nod, fie o instanță specifică), ca precum și o relație de asociere între nodurile 4, indicând faptul că nodurile sunt legate fizic în timpul rulării.

Figura prezintă principalele elemente ale notației utilizate în diagrama de plasare. Pentru a arăta că o entitate face parte dintr-o altă entitate, fie este utilizată o relaţie de dependenţă „desfăşurare” 5, fie forma unei entităţi este plasată în interiorul formei altei entităţi 6. O descriere detaliată a diagramei este dată în capitolul 3.

        Unified Modeling Language (UML) este un limbaj pentru specificarea, vizualizarea, proiectarea și documentarea sistemelor software, precum și a modelelor de afaceri și a altor sisteme non-software. UML este o combinație de tehnici de inginerie care au fost utilizate anterior cu succes în modelarea sistemelor mari și complexe.

        Creatorii UML îl văd ca pe un limbaj pentru definirea, reprezentarea, proiectarea și documentarea sistemelor software, a sistemelor de afaceri și a altor sisteme de diferite tipuri. UML definește o notație și un metamodel. Notația este o colecție de obiecte grafice care sunt utilizate în modele; este sintaxa unui limbaj de modelare.

        UML oferă instrumente expresive pentru crearea de modele vizuale care:

• sunt înțelese uniform de toți dezvoltatorii implicați în proiect;
• sunt mijloacele de comunicare în cadrul proiectului.

        Limbajul de modelare unificat (UML):

• nu depinde de limbaje de programare orientate pe obiecte (OO);
• nu depinde de metodologia de dezvoltare a proiectului utilizată;
• poate suporta orice limbaj de programare OO.

        UML este open source și are mijloacele de a extinde nucleul de bază. În UML, clasele, obiectele și componentele pot fi descrise în mod semnificativ în diferite domenii, adesea foarte diferite unele de altele.

Diagrame UML

        La dispoziția proiectantului de sistem, Rational Rose oferă următoarele tipuri de diagrame, a căror creare secvențială vă permite să obțineți o imagine completă a întregului sistem proiectat și a componentelor sale individuale:

• Diagrama cazurilor de utilizare (diagramele precedentelor);
• Diagrama de implementare (diagrame de topologie);
• Diagrama de stat (diagrame de stare);
• Diagrama de interacțiune (diagrame de interacțiune); Diagrama de activitate (diagramele de activitate);
• Diagrama secvenței (diagramele secvențelor de acțiuni);
• Diagrama de colaborare (diagramele de colaborare);
• Diagrama de clasă (diagramele de clasă);
• Diagrama componentelor (diagramele componentelor);
• Diagrame de comportament (diagrame de comportament);
• Diagrama activității (diagrama activității);
• Diagrame de implementare (diagrame de implementare);

        Fiecare dintre aceste diagrame completează o vedere diferită a modelului de sistem. În același timp, diagrama cazurilor de utilizare reprezintă modelul conceptual al sistemului, care este punctul de plecare pentru construirea tuturor celorlalte diagrame. Diagrama de clasă este un model logic care reflectă aspectele statice ale construcției structurale a sistemului, iar diagramele de comportament, care sunt și varietăți ale modelului logic, reflectă aspectele dinamice ale funcționării acestuia. Diagramele de implementare servesc pentru a reprezenta componentele unui sistem și se referă la modelul său fizic.

        Dintre diagramele enumerate mai sus, unele servesc la desemnarea a două sau mai multe subtipuri. Ca reprezentări independente, sunt utilizate următoarele diagrame: cazuri de utilizare, clase, stări, activități, secvență, cooperare, componente și implementare.

        Există trei tipuri de indicii vizuale pentru diagramele UML care sunt importante în ceea ce privește informațiile pe care le conțin:

• conexiuni, care sunt reprezentate prin linii diferite pe plan;
• text, cuprinse în limitele formelor geometrice individuale;
• simboluri grafice, afișat lângă imaginile grafice.

        La reprezentarea grafică a diagramelor, se recomandă să respectați următoarele reguli:

• fiecare diagramă trebuie să fie o reprezentare completă a unui fragment din tematica modelată;
• entitățile modelului prezentat în diagramă trebuie să fie de același nivel conceptual;
• toate informațiile despre entități trebuie să fie prezentate în mod explicit în diagramă;
• diagramele nu trebuie să conțină informații contradictorii;
• diagramele nu trebuie supraîncărcate cu informații textuale;
• fiecare diagramă trebuie să fie autosuficientă pentru interpretarea corectă a tuturor elementelor sale;
• numărul de tipuri de diagrame necesare pentru a descrie un anumit sistem nu este strict fixat și este determinat de dezvoltator;
• modelele de sistem ar trebui să conțină doar acele elemente care sunt definite în notația limbajului UML.

Entități din UML

        UML definește patru tipuri de entități: structurale, comportamentale, de grupare și adnotare. Entitățile sunt principalele elemente orientate pe obiecte ale limbajului, cu ajutorul cărora se creează modele.

        Entități structurale sunt substantive în modelele UML. De regulă, ele reprezintă părți statice ale modelului, corespunzătoare elementelor conceptuale sau fizice ale sistemului. Exemple de entități structurale sunt „clasă”, „interfață”, „cooperare”, „caz de utilizare”, „componentă”, „nod”, „actor”.

        Entități comportamentale sunt componente dinamice ale modelului UML. Acestea sunt verbe care descriu comportamentul modelului în timp și spațiu. Există două tipuri principale de entități comportamentale:

• interacțiunea este un comportament, a cărui esență este schimbul de mesaje între obiecte într-un context specific pentru atingerea unui scop specific;
• automat - un algoritm comportamental care determină succesiunea stărilor prin care trece un obiect sau o interacțiune ca răspuns la diverse evenimente.

        Gruparea entităților sunt părțile organizatorice ale modelului UML. Acestea sunt blocurile în care modelul poate fi descompus. Există o singură astfel de entitate primară - este un pachet.

        Pachetele sunt un mecanism general de organizare a articolelor în grupuri. Entitățile structurale, comportamentale și alte entități de grupare pot fi plasate într-un pachet. Spre deosebire de componentele care există de fapt în timpul rulării programului, pachetele sunt de natură pur conceptuală, adică există doar în timpul dezvoltării.

        Entități de adnotare sunt părți explicative ale modelului UML: comentarii pentru descriere suplimentară, clarificări sau observații la orice element al modelului. Există un singur tip de bază de elemente de adnotare - nota. O notă este folosită pentru a furniza comentarii sau restricții asupra diagramelor, exprimate ca text informal sau formal.

Relațiile în UML

        UML definește următoarele tipuri de relații: dependență, asociere, generalizare și implementare. Aceste relații sunt constructele de legare de bază ale UML și la fel sunt utilizate entitățile pentru a construi modele.

        Dependenţă- aceasta este o relație semantică între două entități, în care o modificare a uneia dintre ele, independentă, poate afecta semantica celeilalte, dependente.

        Asociere- o relație structurală care descrie totalitatea relațiilor semantice sau logice dintre obiecte.

        Generalizare este o relație în care un obiect element specializat (copil) poate fi înlocuit cu un obiect element generic (strămoș). În același timp, în conformitate cu principiile programării orientate pe obiecte, copilul (copilul) moștenește structura și comportamentul strămoșului său (părinte).

        Realizare este o relație semantică între clasificatori, în care un clasificator definește o obligație, iar celălalt garantează îndeplinirea acesteia. Relația de implementare apare în două cazuri:

• între interfețe și clasele sau componentele lor de implementare;
• între precedente şi cooperările care le implementează.

Mecanisme generale UML

        UML folosește așa-numitele mecanisme generale pentru a descrie cu acuratețe un sistem:

• specificații;
• adaosuri (ornamente);
• diviziuni (diviziuni comune);
• extensii (mecanisme de extensibilitate).

        UML nu este doar un limbaj grafic. În spatele fiecărui element grafic, se află notația acestuia specificație A care conține reprezentarea textuală a constructului de limbaj corespunzător. De exemplu, o pictogramă de clasă are o specificație care îi descrie atributele, operațiile și comportamentul, deși vizual, într-o diagramă, pictograma reflectă adesea doar o mică parte a acestor informații. Mai mult, poate exista o altă reprezentare a acestei clase în model, care să reflecte aspecte complet diferite ale acesteia, dar, totuși, corespunzătoare specificației. Astfel, notația grafică UML este utilizată pentru a vizualiza sistemul și, cu ajutorul specificațiilor, descrie detaliile acestuia.

        Aproape toată lumea element UML are o imagine grafică unică care oferă o reprezentare vizuală a celor mai importante caracteristici ale sale. Notația entității „clasă” conține numele, atributele și operațiile acesteia. Specificația clasei poate conține alte detalii, cum ar fi vizibilitatea atributelor și operațiunilor, comentarii sau o indicație că clasa este abstractă. Multe dintre aceste detalii pot fi vizualizate ca grafice sau text. adaosuri la dreptunghiul standard care reprezintă clasa.

        Când modelați sisteme orientate pe obiecte, există o anumită Divizia entitati reprezentate.

        În primul rând, există o împărțire în clase și obiecte. O clasă este o abstracție, iar un obiect este o implementare concretă a acelei abstracțiuni. În acest sens, aproape toate constructele limbajului sunt caracterizate de dualitatea „clasă/obiect”. Astfel, există cazuri de utilizare și instanțe de cazuri de utilizare, componente și instanțe de componente, noduri și instanțe de noduri. În reprezentarea grafică, se obișnuiește să se folosească același simbol pentru un obiect ca și pentru o clasă și să se sublinieze numele.

        În al doilea rând, există o împărțire într-o interfață și implementarea acesteia. Interfața declară obligațiile, iar implementarea reprezintă implementarea concretă a acestor obligații și asigură respectarea întocmai a semanticii declarate. Ca atare, aproape toate constructele UML sunt caracterizate prin dualitate interfață/implementare. De exemplu, cazurile de utilizare sunt implementate prin colaborări, în timp ce operațiunile sunt implementate prin metode.

        UML este limbaj deschis, adică permite extensiilor controlate să reflecte caracteristicile modelelor de domenii.

        Mecanismele de extensie UML includ:

• stereotipuri (stereotip) - extinde vocabularul UML, permițându-vă să creați altele noi pe baza elementelor existente ale limbajului, concentrate pe rezolvarea unei probleme specifice;
• valori etichetate - extindeți proprietățile constructelor UML de bază, permițându-vă să includeți informații suplimentare în specificația elementului;
• constrângeri (constrângeri) - extindeți semantica constructelor UML, permițându-vă să creați noi și să anulați regulile existente.

        Împreună, aceste trei mecanisme de extensie a limbii vă permit să o modificați în funcție de nevoile proiectului sau de particularitățile tehnologiei de dezvoltare.

Diagrama de caz de utilizare

        Acest tip de diagramă vă permite să creați o listă de operațiuni pe care le efectuează sistemul. Adesea, acest tip de diagramă se numește diagramă funcțională, deoarece pe baza unui set de astfel de diagrame se creează o listă de cerințe de sistem și se determină un set de funcții realizate de sistem.

Figura - 1. Diagrama de caz de utilizare

        Diagramele de cazuri de utilizare descriu funcționalitatea sistemului sau ceea ce ar trebui să facă sistemul. Dezvoltarea diagramei are următoarele obiective:

• determinați limitele generale și contextul domeniului subiectului modelat;
• să formuleze cerințe generale pentru comportamentul funcțional al sistemului proiectat;
• elaborarea unui model conceptual inițial al sistemului pentru detalierea ulterioară a acestuia sub forma unor modele logice și fizice;
• pregăti documentația inițială pentru interacțiunea dezvoltatorilor de sisteme cu clienții și utilizatorii săi.

        Esența diagramei cazurilor de utilizare este următoarea. Sistemul proiectat este reprezentat ca un set de entități sau actori care interacționează cu sistemul folosind cazuri de utilizare. În acest caz, un actor (actor) sau un actor este orice entitate care interacționează cu sistemul din exterior. Ar putea fi o persoană dispozitiv tehnic, un program sau orice alt sistem care poate servi drept sursă de influență asupra sistemului simulat în modul pe care îl determină însuși dezvoltatorul. Utilizare caz servește pentru a descrie serviciile pe care sistemul le oferă actorului.

        Scopul unui caz de utilizare este de a defini un aspect complet sau o bucată de comportament al unei entități fără a expune structura sa internă. O astfel de entitate poate fi un sistem sau orice element al modelului care are propriul comportament.

        Fiecare caz de utilizare corespunde unui serviciu separat pe care entitatea modelată îl oferă la cererea actorului, adică determină modul în care este utilizată entitatea. Un serviciu care este inițializat la cererea unui actor este o secvență completă indivizibilă de acțiuni. Aceasta înseamnă că după ce sistemul a terminat de procesat cererea, trebuie să revină la starea initiala pentru a fi pregătit pentru următoarele interogări

        Cazurile de utilizare pot fi utilizate atât pentru a specifica cerințe externe pentru sistemul proiectat, cât și pentru a specifica deja comportamentul funcțional sistem existent. Setul de cazuri de utilizare în ansamblu ar trebui să definească toate aspectele posibile ale comportamentului așteptat al sistemului. În plus, cazurile de utilizare stabilesc implicit cerințe care determină modul în care actorii trebuie să interacționeze cu sistemul pentru a putea funcționa corect cu serviciile furnizate. Pentru comoditate, multe cazuri de utilizare pot fi considerate ca un pachet separat.

        Exemple de cazuri de utilizare pot fi următoarele acțiuni: verificarea stării contului curent al clientului, plasarea unei comenzi de achiziție de bunuri, obținerea de informații suplimentare despre bonitatea clientului, afișarea unui formular grafic pe ecranul monitorului și alte acțiuni .

Diagrama de clasă (diagrama de clasă)

        Esențial pentru programarea orientată pe obiecte este dezvoltarea unui model logic al unui sistem sub forma unei diagrame de clasă. Diagrama de clasă (diagrama de clasă) servește la reprezentarea structurii statice a modelului de sistem în terminologia claselor de programare orientată pe obiecte. O diagramă de clasă poate reflecta, în special, diverse relații între entitățile individuale ale domeniului subiectului, cum ar fi obiectele și subsistemele, precum și să descrie structura lor internă și tipurile de relații.

Figura - 2. Diagrama de clasă

        Pictogramele de diagramă vă permit să afișați o ierarhie complexă de sisteme, relații între clase (Clase) și interfețe (Interfețe). Acest tip de diagramă este opus ca conținut diagramei de colaborare, care afișează obiecte de sistem. Rational Rose vă permite să creați clase folosind acest tip de diagramă în diferite notații. ca un nor. Astfel, o clasă este doar un șablon, conform căruia un anumit obiect va fi creat în viitor.

        O diagramă de clasă este un grafic ale cărui vârfuri sunt elemente de tip „clasificator” conectate tipuri variate relaţii structurale. O diagramă de clasă poate conține, de asemenea, interfețe, pachete, relații și chiar instanțe individuale, cum ar fi obiecte și relații.

        clasăîn UML, este folosit pentru a desemna un set de obiecte care au aceeași structură, comportament și relații cu obiectele din alte clase. Grafic, clasa este reprezentată ca un dreptunghi, care poate fi împărțit suplimentar prin linii orizontale în secțiuni sau secțiuni. Aceste secțiuni pot conține numele clasei, atribute (variabile) și operații (metode).

Diagrama de stare (diagrama de stat)

        Fiecare diagramă de stări din UML descrie toate stările posibile ale unei instanțe ale unei anumite clase și secvențele posibile ale tranzițiilor acesteia de la o stare la alta, adică modelează toate modificările stării unui obiect ca reacție la exterior. influențe.

        Diagramele de stat sunt cel mai adesea folosite pentru a descrie comportamentul obiectelor individuale, dar pot fi folosite și pentru a specifica funcționalitatea altor componente ale modelului, cum ar fi cazuri de utilizare, actori, subsisteme, operațiuni și metode.

Figura - 2. Diagrama stărilor

        O diagramă de stare este un grafic un fel special, care reprezintă un oarecare automat. Vârfurile graficului sunt stările posibile ale automatului, reprezentate de simbolurile grafice corespunzătoare, iar arcele indică tranzițiile acestuia de la stare la stare. Diagramele de stat pot fi imbricate pentru a oferi o reprezentare mai detaliată a elementelor individuale ale modelului.

        În metamodelul UML mașinărie este un pachet care definește un set de concepte necesare pentru a reprezenta comportamentul entității modelate ca un spațiu discret cu un număr finit de stări și tranziții.

        Durata sistemului în oricare dintre stările posibile depășește semnificativ timpul petrecut la trecerea de la o stare la alta. Se presupune că în limită timpul de tranziție poate fi egal cu zero (dacă nu se specifică altfel), adică schimbarea stărilor obiectului poate avea loc instantaneu.

        Comportamentul automatului este modelat ca o mișcare secvențială de-a lungul graficului de la vârf la vârf, ținând cont de orientarea arcurilor care le conectează.

        Pentru automatul automat trebuie îndeplinite următoarele condiții obligatorii:

• starea în care poate ajunge un obiect este determinată doar de starea sa actuală și nu depinde de istoria sa;
• la un moment dat, automatul poate fi doar într-una din stările sale. În același timp, automatul poate fi într-o stare separată pentru un timp arbitrar îndelungat dacă nu au loc evenimente;
• timpul petrecut de automat într-o stare sau alta, precum și timpul necesar pentru a ajunge într-o stare sau alta, nu sunt specificate în niciun fel;
• numărul de stări automate trebuie să fie finit și toate acestea trebuie specificate în mod explicit. Pseudo-stările individuale pot să nu aibă specificații (stările inițiale și finale). În acest caz, scopul și semantica lor sunt complet determinate din contextul modelului și al diagramei de stare în cauză;
• graficul automatului nu trebuie să conțină stări și tranziții izolate. Pentru fiecare stare, cu excepția celei inițiale, trebuie definită starea anterioară, iar fiecare tranziție trebuie să conecteze două stări ale automatului;
• automatul nu trebuie să conțină tranziții conflictuale atunci când obiectul poate merge simultan în două sau mai multe stări ulterioare (cu excepția cazului subautomatelor paralele). În limbajul UML, eliminarea conflictului este posibilă pe baza introducerii condițiilor de gardă.

stat este fundamentală nu numai în metamodelul UML, ci și în analiza aplicată a sistemelor. Întregul concept de sistem dinamic se bazează pe conceptul de stare. Semantica statului în limbajul UML are o serie de caracteristici specifice.

        În UML, o stare este o metaclasă abstractă folosită pentru a modela o anumită situație în care anumite condiții sunt adevărate. Starea poate fi specificată ca un set de valori specifice ale atributelor de clasă sau obiect. Modificările la valorile atributelor individuale vor reflecta o schimbare a stării clasei sau obiectului modelat.

Diagrama activității

        La modelarea comportamentului unui sistem proiectat sau analizat, devine necesar nu doar prezentarea procesului de modificare a stărilor acestuia, ci și detalierea caracteristicilor implementării algoritmice și logice a operațiilor efectuate de sistem.

        De fapt tipul dat diagramele pot fi, de asemenea, folosite pentru a reflecta stările obiectului care se modelează, cu toate acestea, scopul principal al diagramei de activitate este de a reflecta procesele de afaceri ale obiectului. Acest tip de diagramă vă permite să afișați nu numai succesiunea proceselor, ci și ramificarea și chiar sincronizarea proceselor.

        Acest tip de diagramă vă permite să proiectați algoritmi pentru comportamentul obiectelor de orice complexitate și poate fi folosit și pentru a crea diagrame bloc.

        UML folosește diagrame de activitate pentru a modela procesul de efectuare a operațiunilor. Notația lor grafică este similară în multe privințe cu notația diagramă de stat, deoarece aceste diagrame au și simboluri de stare și de tranziție. Fiecare stare din diagrama de activitate corespunde executării unei operații elementare, iar trecerea la următoarea stare se realizează numai când această operație este finalizată.

        Astfel, diagramele de activitate pot fi considerate un caz special de diagrame de stare. Acestea vă permit să implementați în UML caracteristicile controlului procedural și sincron, datorită finalizării activităților și acțiunilor interne. Direcția principală de utilizare a diagramelor de activitate este vizualizarea caracteristicilor implementării operațiilor de clasă, atunci când este necesar să se prezinte algoritmi pentru executarea acestora.

        În contextul UML activitate este un set de calcule individuale efectuate de automat, care conduc la un rezultat sau acțiune (acțiune). Diagrama de activitate arată logica și succesiunea tranzițiilor de la o activitate la alta, iar atenția analistului este concentrată asupra rezultatelor. Rezultatul unei activități poate duce la o schimbare a stării sistemului sau la returnarea unei anumite valori.

        Stare de acțiune este un caz special al unei stări cu o acțiune de intrare și cel puțin o tranziție de ieșire a stării. Această tranziție presupune implicit că acțiunea de intrare a fost deja finalizată. Starea de acțiune nu poate avea tranziții interne deoarece este elementară. Uz comun Starea de acțiune constă în modelarea unui pas al execuției unui algoritm (procedură) sau a unui flux de control.

Diagrama secvenței

        Când se analizează diagramele de stare și activitate, sa observat că, deși aceste diagrame sunt folosite pentru a specifica dinamica comportamentului sistemelor, timpul nu este prezent în mod explicit în ele. Aspectul temporal al comportamentului poate avea o importanță semnificativă atunci când se modelează procese sincrone care descriu interacțiunile obiectelor. Diagramele de secvență sunt folosite pentru a modela interacțiunea obiectelor în timp în limbajul UML.

        Diagramele secvențe arată numai acele obiecte care sunt direct implicați în interacțiune. Punctul cheie pentru diagramele secvențe este dinamica interacțiunii obiectelor în timp.

        În UML, o diagramă de secvență are două dimensiuni, așa cum ar fi. Primul de la stânga la dreapta ca linii verticale, fiecare dintre acestea ilustrând linia de viață a unui obiect individual care participă la interacțiune. Obiectul cel mai din stânga din diagramă este obiectul care este inițiatorul interacțiunii. În dreapta, este înfățișat un alt obiect, care interacționează direct cu primul. Astfel, toate obiectele din diagrama de secvență formează o anumită ordine, determinată de ordinea sau gradul de activitate al obiectelor atunci când interacționează între ele.

        Grafic, fiecare obiect este reprezentat printr-un dreptunghi și este situat în partea de sus a liniei sale de viață. În interiorul dreptunghiului sunt scrise numele obiectului și numele clasei, separate prin două puncte. În acest caz, întreaga înregistrare este subliniată, ceea ce este un semn al obiectului.

        A doua dimensiune a unei diagrame secvențe este axa verticală a timpului, de sus în jos. Partea de sus a diagramei corespunde momentului inițial de timp. Interacțiunile obiectelor se realizează prin mesaje care sunt trimise de un obiect către altul. Mesajele sunt afișate ca săgeți orizontale cu numele mesajului, iar ordinea lor este determinată de momentul în care au apărut. Adică, mesajele mai sus în diagrama de secvență sunt inițiate înaintea celor de jos. Scara pe axa timpului nu este indicată, deoarece diagrama de secvență modelează doar ordonarea temporală a interacțiunilor anterioare-ulterioare.

Diagrama de colaborare

        caracteristica principală Diagramele de cooperare constă în capacitatea de a reprezenta grafic nu numai succesiunea interacțiunii, ci și toate relațiile structurale dintre obiectele care participă la această interacțiune.

Figura - 3. Diagrama cooperării

        Acest tip de diagramă vă permite să descrieți interacțiunea obiectelor, făcând abstracție din secvența de transmitere a mesajelor. Acest tip de diagramă reflectă într-o formă compactă toate mesajele primite și transmise ale unui anumit obiect și tipurile acestor mesaje.

        În primul rând, pe diagrama cooperării, obiectele care participă la interacțiune sunt reprezentate sub formă de dreptunghiuri, cuprinzând numele obiectului, clasa acestuia și, eventual, valorile atributelor. Mai mult, ca și în diagrama de clasă, asocierile dintre obiecte sunt indicate sub forma unor linii de legătură diferite. În acest caz, puteți specifica în mod explicit numele asociației și rolurile pe care obiectele le joacă în această asociere. În plus, pot fi afișate legături dinamice - fluxuri de mesaje. Ele sunt reprezentate și ca linii de legătură între obiecte, deasupra cărora există o săgeată care indică direcția, numele mesajului și numărul de serie în secvența generală de inițializare a mesajului.

        Spre deosebire de diagrama secvență, o diagramă de colaborare arată doar relațiile dintre obiectele care joacă roluri specifice într-o interacțiune. Acest grafic nu arată timpul ca o dimensiune separată. Prin urmare, succesiunea interacțiunilor și a fluxurilor paralele poate fi definită folosind numerele de secvență. Prin urmare, dacă este necesar să specificați în mod explicit relațiile dintre obiecte în timp real, este mai bine să faceți acest lucru într-o diagramă de secvență.

        Concept cooperare este unul dintre conceptele fundamentale din UML. Acesta servește la desemnarea unui set de obiecte care interacționează cu un scop specific în contextul general al sistemului care se modelează. Scopul cooperării în sine este de a specifica caracteristicile implementării celor mai semnificative operațiuni individuale din sistem. Cooperarea definește structura comportamentului sistemului în ceea ce privește interacțiunea participanților la această cooperare.

        Cooperarea poate fi reprezentată pe două niveluri:

• nivelul de specificație - arată rolurile clasificatorilor și rolul asociațiilor în interacțiunea avută în vedere;
• nivel de instanță - indică instanțele și relațiile care formează rolurile individuale în colaborare.

        O diagramă de colaborare la nivel de specificație arată rolurile jucate de elementele implicate în interacțiune. Elementele cooperării la acest nivel sunt clasele și asociațiile, care denotă roluri separate de clasificatori și asocieri între participanții la cooperare.

        O diagramă de colaborare la nivel de instanță este reprezentată de o colecție de obiecte (instanțe de clasă) și relații (instanțe de asociere). În același timp, linkurile sunt completate cu săgeți pentru mesaje. Pe nivelul dat sunt afișate doar obiectele care au legătură directă cu implementarea operației sau a clasificatorului. În acest caz, nu este deloc necesar să descriem toate proprietățile sau toate asocierile, deoarece doar rolurile clasificatorilor sunt prezente pe diagrama de cooperare, dar nu și clasificatorii înșiși. Astfel, în timp ce clasificatorul necesită o descriere completă a tuturor instanțelor sale, rolul clasificatorului necesită descrierea doar a acelor proprietăți și asocieri care sunt necesare pentru a participa la o anumită cooperare.

        De aici rezultă un corolar important. Același set de obiecte poate participa la diferite colaborări. În funcție de cooperarea luată în considerare, atât proprietățile obiectelor individuale, cât și legăturile dintre ele se pot schimba. Acesta este ceea ce deosebește o diagramă de colaborare de o diagramă de clasă, care trebuie să indice toate proprietățile și asocierile dintre elementele diagramei.

Diagrama componentelor

        Acest tip de diagramă este folosit pentru a aloca clase și obiecte componentelor în proiectarea fizică a sistemului. Acest tip de diagramă este adesea denumit diagrame de module.

Figura - 4. Diagrama componentelor

        Un proiect de sistem software complet este o colecție de straturi fizice, care trebuie să fie în concordanță între ele. În limbajul UML, pentru reprezentarea fizică a modelelor de sistem se folosesc diagrame de implementare (diagrame de implementare), care includ diagrama componentelorși diagrama de implementare.

        O diagramă de componente, spre deosebire de diagramele discutate anterior, descrie caracteristicile reprezentării fizice a sistemului. Vă permite să determinați arhitectura sistemului în curs de dezvoltare prin stabilirea unor dependențe între componentele software, care pot fi cod sursă și cod executabil. Elementele grafice principale ale unei diagrame de componente sunt componentele, interfețele și dependențele dintre ele.

        Diagrama componentelor este dezvoltată în următoarele scopuri:

• vizualizare structura de ansamblu codul sursă al sistemului software;
• specificațiile versiunii executabile a sistemului software;
• asigurarea reutilizarii fragmentelor individuale de cod de program;
• reprezentări ale schemelor conceptuale și fizice ale bazelor de date.

        Atât analiștii de sistem, cât și arhitecții și programatorii participă la dezvoltarea diagramelor componentelor. Diagrama componentelor oferă o tranziție consistentă de la reprezentarea logică la implementarea specifică a proiectului sub formă de cod de program. Unele componente pot exista doar în etapa de compilare a codului programului, altele în etapa de execuție a acestuia. Diagrama componentelor reflectă dependențele generale dintre componente, considerându-le pe acestea din urmă ca clasificatori.

        UML folosește un termen special pentru a reprezenta entitățile fizice - componentă. Componenta implementează un anumit set de interfețe și servește ca o desemnare generală a elementelor reprezentării fizice a modelului. Pentru reprezentare grafică componenta folosește un simbol special - un dreptunghi cu două dreptunghiuri mai mici inserate în stânga. În interiorul dreptunghiului mare este scris numele componentei și, dacă este necesar, câteva Informații suplimentare. Imaginea acestui simbol poate varia ușor în funcție de natura informațiilor asociate cu componenta.

Diagrama de implementare

        Acest tip de diagramă este conceput pentru a analiza hardware-ul sistemului, adică hardware-ul, nu software-ul. În traducere directă din engleză, Deployment înseamnă „implementare”, dar termenul „topologie” reflectă mai exact esența acestui tip de diagramă.

Figura - 5. Diagrama de implementare

        Reprezentarea fizică a unui sistem software nu poate fi completă dacă nu există informații despre ce platformă și care facilitati de calcul a fost implementat. Dacă se dezvoltă un program care rulează local pe computerul utilizatorului și nu utilizează dispozitive și resurse periferice, atunci nu este nevoie să dezvolte diagrame suplimentare. La dezvoltarea aplicațiilor de întreprindere, prezența unor astfel de diagrame poate fi extrem de utilă pentru rezolvarea problemelor de amplasare rațională a componentelor în vederea utilizare eficientă resurse de rețea de calcul și comunicații distribuite, securitate și altele.

        UML utilizează diagrame de implementare pentru a reprezenta configurația generală și topologia unui sistem software distribuit.

        Diagrama de implementare este concepută pentru a vizualiza elementele și componentele programului care există doar în etapa de rulare. În acest caz, sunt prezentate doar componentele instanței de program care sunt fișiere executabile sau biblioteci dinamice. Acele componente care nu sunt utilizate în timpul execuției nu sunt afișate în diagrama de implementare. Deci, componentele cu coduri sursă de program pot fi prezente doar pe diagrama componentelor. Ele nu sunt afișate în diagrama de implementare.

        O diagramă de implementare conține reprezentări grafice ale procesoarelor, dispozitivelor, proceselor și relațiilor lor. Spre deosebire de diagramele de reprezentare logică, diagrama de implementare este aceeași pentru sistemul în ansamblu, deoarece trebuie să reflecte pe deplin caracteristicile implementării sale. Dezvoltarea unei diagrame de implementare este de obicei ultimul pas în specificarea unui model de sistem software.

        Când proiectați o diagramă de implementare, obiectivele sunt:

• determina distribuția componentelor sistemului pe nodurile sale fizice;
• arată conexiunile fizice între toate nodurile implementării sistemului în etapa de execuție a acestuia;
• identificați blocajele sistemului și reconfigurați topologia acestuia pentru a obține performanța necesară.

        Diagramele de implementare sunt dezvoltate în comun de analiști de sistem, ingineri de rețea și ingineri de sisteme.

Caracteristici ale interfeței desktop Rational Rose

        Instrumentul Rational Rose CASE implementează standarde general acceptate pentru interfața de operare a programului, similare mediilor de programare vizuală bine-cunoscute. După instalarea Rational Rose pe computerul utilizatorului, ceea ce nu provoacă aproape deloc dificultăți nici pentru începători, rularea acestui program în mediul MS Windows 95/98 duce la apariția unei interfețe de lucru pe ecran (Fig. 6).

Figura - 6. Vedere generală a interfeței de operare a programului Rational Rose

        Interfața de lucru Rational Rose este formată din diverse elemente, principalele fiind:

• Meniul principal al programului
• Fereastra diagramă
• Fereastra de documentare
• fereastra browserului
• fereastra de jurnal

Să luăm în considerare pe scurt scopul și funcțiile principale ale fiecăruia dintre aceste elemente.

Meniul principal al programului

Meniul principal al programului este realizat în standardul general acceptat și are următoarea formă (Fig. 7).

Elementele de meniu separate, al căror scop este clar din numele lor, combină operațiuni similare legate de întregul proiect în ansamblu. Unele dintre elementele de meniu conțin funcții binecunoscute (deschiderea unui proiect, tipărirea diagramelor, copierea în clipboard și lipirea diferitelor elemente de diagramă din clipboard). Altele sunt atât de specifice încât pot necesita efort suplimentar pentru a învăța (opțiuni pentru generarea codului programului, verificarea consistenței modelelor, conectarea modulelor suplimentare).

Figura - 7. Aspect meniul principal al programului

Bara de instrumente standard

Bara de instrumente standard este situată sub meniul principal al programului și arată astfel (Fig. 8). Unele dintre instrumente nu sunt disponibile (noul proiect nu are niciun element). Bara de instrumente standard oferă acces rapid la acele comenzi de meniu care sunt utilizate cel mai des de dezvoltatori.

Figura - 8. Aspectul barei de instrumente standard

Utilizatorul poate personaliza aspectul acestui panou la discreția sa. Pentru a face acest lucru, selectați elementul de meniu Instrumente -> Opțiuni (Instrumente -> Opțiuni) și deschideți fila Bare de instrumente (Bare de instrumente). În acest fel, puteți afișa sau ascunde diverse butoane de instrumente, precum și să le modificați dimensiunea.

fereastra browserului

Fereastra implicită a browserului este situată în partea stângă a interfeței de lucru, sub bara de instrumente standard (Fig. 9).

Browserul organizează vizualizările modelului într-o structură ierarhică care facilitează navigarea și găsirea oricărui element de model din proiect. În acest caz, orice element pe care dezvoltatorul îl adaugă modelului este afișat imediat în fereastra browserului. În consecință, selectând un element în fereastra browserului, îl putem vizualiza în fereastra diagramă sau îi putem modifica specificația. Browserul vă permite, de asemenea, să organizați elementele modelului în pachete și să mutați elemente între diferite vederi ale modelului. Dacă se dorește, fereastra browserului poate fi plasată într-un alt loc al interfeței de lucru sau ascunsă cu totul, folosind elementul de meniu Vizualizare (Vizualizare). De asemenea, puteți redimensiona browser-ul trăgând marginea cadrului său exterior cu mouse-ul.

Figura - 9. Aspectul browserului

Bară de instrumente specială

O bară de instrumente specială este situată între fereastra browserului și fereastra diagramă în partea de mijloc a interfeței de lucru. În mod implicit, o bară de instrumente este oferită pentru construirea unei diagrame de clasă model (Fig. 10).

Figura - 10. Apariția unei bare de instrumente speciale pentru o diagramă de clasă

Puteți schimba locația barei de instrumente personalizate mutând cadrul barei de instrumente în locația dorită. De asemenea, puteți personaliza compoziția panoului prin adăugarea sau eliminarea butoanelor individuale corespunzătoare anumitor instrumente. Atribuțiile butoanelor pot fi găsite în sfaturi cu instrumente care apar după ce treceți cursorul mouse-ului peste butonul corespunzător.

Fereastra diagramă

Fereastra diagramă este zona principală de lucru a interfeței sale, în care sunt vizualizate diferite reprezentări ale modelului de proiect. În mod implicit, fereastra diagramei este situată în partea dreaptă a interfeței de lucru, dar locația și dimensiunea acesteia pot fi, de asemenea, modificate. La dezvoltarea unui proiect nou, dacă nu a fost folosit expertul de proiect, fereastra diagramei este o zonă goală care nu conține niciun element de model (Fig. 11).

Numele diagramei care se află în această fereastră este indicat în bara de titlu a programului (linia de sus a programului) sau, dacă fereastra nu este maximizată la ecran complet, în bara de titlu a ferestrei diagramei. Mai multe diagrame pot fi prezente în fereastra diagramă în același timp, dar numai una dintre ele poate fi activă. De exemplu, în fig. 11 diagrama de desfășurare este cea activă, deși există și alte diagrame. Comutarea între diagrame se poate face selectând vizualizarea dorită pe bara de instrumente standard sau prin elementul de meniu Window (Window). Când este activată o vizualizare de diagramă individuală, aspectul unei bare de instrumente speciale se modifică, care este personalizată pentru o anumită vizualizare a diagramei.

Figura - 11. Aspectul ferestrei diagramei cu diferite vederi ale modelului

Fereastra de documentare

Este posibil ca fereastra de documentație implicită să nu fie prezentă pe ecran. În acest caz, acesta poate fi activat prin intermediul articolului de meniu View -> Documentation (View-> Documentation), după care va apărea sub browser (Fig. 12).

Fereastra de documentare, după cum sugerează și numele, este destinată documentării elementelor vederii modelului. Poate înregistra o varietate de informații și ceea ce este important - în rusă. Aceste informații sunt ulterior convertite în comentarii și nu afectează în niciun fel logica execuției codului programului.

Fereastra de documentație activează informațiile care se referă la un singur element selectat al diagramei. În acest caz, puteți selecta un element fie în fereastra browserului, fie în fereastra diagramă. Când un element nou este adăugat în diagramă (de exemplu, o clasă), documentația pentru acesta este generată automat, care este goală (Fără documentație). Ulterior, dezvoltatorul introduce în mod independent informațiile explicative necesare, care sunt reținute și pot fi modificate în timpul lucrului la proiect.

La fel ca pentru alte ferestre ale interfeței de lucru, puteți modifica dimensiunea și poziția ferestrei de documentație.

Figura - 12. Apariția ferestrei de documentație

fereastra de jurnal

Fereastra de jurnal (Log) este destinată înregistrării automate a diverselor informații de serviciu generate în timpul lucrului cu programul. Jurnalul înregistrează timpul și natura acțiunilor dezvoltatorului, cum ar fi actualizarea modelului, personalizarea meniurilor și barelor de instrumente și raportarea erorilor care apar în timpul generării codului.

Fereastra de jurnal este întotdeauna prezentă pe interfața de lucru în zona ferestrei diagramei (Fig. 13). Cu toate acestea, poate fi ascuns de alte ferestre de diagramă sau poate fi minimizat. Puteți activa fereastra de jurnal prin meniul Fereastră-> Jurnal (Fereastră-> Jurnal). În acest caz, este afișat deasupra altor ferestre în zona dreaptă a interfeței de lucru. Nu puteți elimina complet această fereastră, puteți doar să o minimizați.

Figura - 13. Aspectul ferestrei de jurnal

Concluzie

        În timp, limbajul UML va deveni „Esperantoul” pe care matematicienii, analiștii de sisteme, fizicienii, programatorii, managerii, economiștii și specialiștii din alte profesii îl pot comunica, prezentându-și cunoștințe profesionaleîntr-un mod unitar. Într-adevăr, în esență, fiecare dintre specialiști operează cu reprezentări model în domeniul său de cunoaștere. Și tocmai acest aspect de model poate fi specificat prin intermediul limbajului UML.

        În acest sens, importanța limbajului UML crește semnificativ, pe măsură ce dobândește din ce în ce mai mult caracteristicile unui limbaj de reprezentare a cunoștințelor. În același timp, prezența în limbajul UML a mijloacelor vizuale de reprezentare a structurii și comportamentului modelului face posibilă realizarea unei reprezentări adecvate a cunoștințelor declarative și procedurale și, nu mai puțin important, stabilirea unei corespondențe semantice între aceste forme. de cunoaștere. Toate aceste caracteristici ale limbajului UML ne permit să concluzionam că are cele mai serioase perspective în viitorul apropiat.

Acest articol vorbește despre noua era a dezvoltării software, impactul acesteia asupra noilor cerințe propuse UML și cele mai bune metode de îndeplinire a acestora.
  7. „Modelarea datelor în Rational Rose” Sergey Trofimov Descrie modul de modelare a reprezentării fizice a datelor folosind Rational Rose
  8. Limbajul UML. Înțelegerea generală a limbajului UML: structuri, elemente grafice și diagrame ale limbajului.
  9. UML practic. Acest document este o traducere a documentului „UML practic. O introducere practică pentru dezvoltatori”. O introducere practică pentru dezvoltatori
  10. „Limbajul standard de modelare orientat pe obiecte UML” Vendrov Alexander Mikhailovici. Istoria creării UML
  11. UML - Limbaj de modelare unificat. Acest material conține informații inițiale despre metodele de descriere a sistemelor software și notațiile utilizate în UML
  12. Limbajul UML. Manualul utilizatorului. Autori: Grady Booch, James Rumbaugh, Ivar Jacobson
  13. „Diagramele UML în Rational Rose” Serghei Trofimov
  14. "Analiză și proiectare. Modelare vizuală (UML) Rational Rose" Konstantin Domolego
  15. Biblioteca lui Ghenadi Vernikov. Descrieri complete standarde de proiectare și modelare.
  16. „Un exemplu de descriere a domeniului de studiu folosind UML în dezvoltarea sistemelor software” E.B. Zolotukhina, R.V. Alfimov. Într-un articol despre exemplu concret demonstrează o posibilă abordare a modelării domeniului bazată pe utilizarea limbajului de modelare unificat (UML)

       

UML (Unified Modeling Language - unified modeling language) - un limbaj de descriere grafică pentru modelarea obiectelor în domeniul dezvoltării software. UML este un limbaj general, este un standard deschis care folosește notația grafică pentru a crea un model abstract al unui sistem, numit model UML. UML a fost creat pentru a defini, vizualiza, proiecta și documenta în principal sisteme software. UML nu este un limbaj de programare, dar generarea de cod este posibilă în instrumentele de executare a modelelor UML ca cod interpretat. Wikipedia

Produse Comerciale

Microsoft Visio

Tip: software comercial

Popular software de la Microsoft, care vă permite să desenați diagrame bogate, inclusiv UML:

Începând cu versiunea 2010, a devenit posibilă publicarea diagramelor pe web (SharePoint + Visio Services):

Visio Viewer- program gratuit, care vă permite să vizualizați diagramele Visio create anterior. Puteți descărca de la %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelare,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Secvența%20Diagrama%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Folosește%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Vizualizare%20și%20Modelare%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

• %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%0A
• %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrame%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrame
%0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Vizualizarea%20și%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Capabilitati:

• Diagrama cazurilor de utilizare (diagramele precedentelor);
• Diagrama de implementare (diagrame de topologie);
• Diagrama de stat (diagrame de stare);
• Diagrama de activitate (diagramele de activitate);
• Diagrama de interacțiune (diagrame de interacțiune);
• Diagrama secvenței (diagramele secvențelor de acțiuni);
• Diagrama de colaborare (diagramele de colaborare);
• Diagrama de clasă (diagramele de clasă);
• Diagrama componentelor (diagramele componentelor).

Capturi de ecran:

programe open source

StarUML

Capabilitati:

• Suport UML 2.0
• MDA (Arhitectură condusă de model)
• Plug-in Architecture (puteți scrie în limbi compatibile COM: C++, Delphi, C#, VB, ...)

StarUML este scris în principal în Delphi, dar puteți adăuga componente în alte limbi, cum ar fi C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Mai jos sunt câteva capturi de ecran.

Diagrama de clasă:

Diagrama cazului de utilizare:

ArgoUML

Diagrame acceptate:

• clasă
• Stat
• cazuri de utilizare
• Activitate
• Colaborare
• Implementare
• Secvenţă

Capabilitati:

• Suport pentru nouă diagrame UML 1.4
• Independent de platformă (Java 5+)
• Metamodelul standard UML 1.4
• Suport XMI
• Exportați în GIF, PNG, PS, EPS, PGML și SVG
• Limbi: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• Suport OCL
• Înainte, inginerie inversă

Captură de ecran: