Caracteristicile generale ale limbajului UML. Diagrama UML. Tipuri de diagrame UML

12.12.2023

O diagramă UML este un limbaj specializat de descriere grafică destinat modelării obiectelor în dezvoltarea diverselor software. Limbajul 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 cod separat pe baza acestuia.

De ce este nevoie?

Utilizarea UML nu se termină cu modelarea tuturor tipurilor de software. De asemenea, acest limbaj este utilizat în mod activ astăzi pentru modelarea diferitelor procese de afaceri, realizarea proiectării sistemului și, de asemenea, afișarea structurilor organizaționale.

Cu UML, dezvoltatorii de software pot asigura acordul complet în ceea ce privește utilizarea simboluri grafice pentru a reprezenta concepte comune precum: componentă, generică, clasă, comportament și agregare. Datorită acestui fapt, se obține un grad mai mare de concentrare pe arhitectură și design.

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

Diagrama de clasă

O diagramă de clasă UML este o diagramă structurală 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 furnizează 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

O diagramă de componente UML este o diagramă de structură complet statică. Are scopul de a demonstra împărțirea unui anumit sistem software asupra diferitelor componente structurale, precum și a conexiunilor dintre acestea. O diagramă de componente UML poate folosi tot felul de modele, biblioteci, fișiere, pachete, executabile și multe alte elemente ca atare.

Diagrama structurii compozite/compozite

O diagramă 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 situate în structura internă a clasei.

Un subtip al acestora este diagrama de colaborare UML, care este folosită pentru a demonstra rolurile, precum și interacțiunea diferitelor clase în limitele cooperării. Sunt destul de convenabile dacă trebuie să modelați modele de design.

Este demn de remarcat faptul că vederile de clasă UML și diagrama structurii compozite pot fi utilizate simultan.

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 în 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 artefact și componenta pe care o implementează.

Diagrama obiectului

Această vizualizare vă permite să vedeți o imagine completă sau parțială sistem creat la un anumit moment în timp. Afișează complet toate instanțele claselor unui anumit sistem, indicând valorile curente ale parametrilor acestora, precum și conexiunile dintre ele.

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ă o divizare strictă între mai multe diagrame structurale, ca urmare a căreia utilizarea lor se găsește cel mai adesea doar pentru comoditate și nu are nicio semnificație semantică. Este demn 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 grupe după un anumit criteriu pentru a simplifica structura, precum și pentru a organiza lucrul cu modelul unui sistem dat.

Diagrama de activitate

O diagramă de activitate UML descrie descompunerea unei activități specifice în mai multe componente. În acest caz, conceptul de „activitate” este specificarea unui anumit comportament executabil sub formă de execuție paralelă, precum și execuție secvențială coordonată a diferitelor elemente subordonate - tipuri imbricate de activități și diverse acțiuni, unite de fluxuri care merg de la ieșiri. a unui anumit nod la intrările altuia.

Diagramele de activitate UML sunt adesea folosite pentru a modela diferite procese de afaceri, calcule paralele și secvențiale. Printre altele, ele simulează tot felul de proceduri tehnologice.

Diagrama mașinii

Acest tip este numit și puțin diferit - diagrama de stare UML. Are o mașină cu stări finite 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 interacțiune ca răspuns la anumite evenimente din viața sa, precum și răspunsul obiectului la astfel de evenimente. O mașină de stări care utilizează o diagramă de stare UML este atașată unui element sursă și utilizată pentru a defini comportamentul instanțelor sale.

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

Folosiți diagrame de caz

O diagramă a cazurilor de utilizare UML descrie 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 orice dezvoltator să poată discuta în comun despre comportamentul și funcționalitatea unui anumit sistem.

Dacă o diagramă de caz de utilizare UML este utilizată în procesul de modelare a sistemului, atunci analistul va:

Separați clar sistemul care se modelează de mediul său.
Dezvăluie personaje, modalitățile de interacțiune a acestora cu acest sistem, precum și funcționalitatea așteptată a acestuia.
Setați în glosar ca disciplină diferite concepte care se referă la o descriere detaliată a funcționalității unui sistem dat.

Dacă o diagramă de utilizare este dezvoltată în UML, procedura începe cu o descriere text, care se obține atunci când se lucrează cu clientul. Este de remarcat faptul că diferite cerințe nefuncționale sunt complet omise în procesul de elaborare a unui model de caz de utilizare și va fi generat un document separat pentru acestea.

Comunicatii

O diagramă de comunicare, la fel ca o diagramă de secvență UML, este tranzitivă, adică exprimă interacțiunea, dar în același timp o demonstrează în moduri diferite, iar dacă este necesar, unul poate fi convertit în celălalt cu gradul de precizie necesar.

Diagrama de comunicare reflectă interacțiunile care apar între diferitele elemente ale structurii compozite, precum și rolurile cooperării. Principala diferență dintre aceasta și o diagramă de secvență este că face relațiile dintre mai multe elemente destul de explicite și nu folosește timpul ca dimensiune separată.

Acest tip se distinge printr-un format absolut liber pentru aranjarea mai multor obiecte și conexiuni î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 și, ulterior, continuă în direcția în care mesajele sunt transmise de la un obiect la altul.

În cea mai mare parte, aceste diagrame arată exact aceleași informații pe care ni le oferă o diagramă de secvență, dar deoarece utilizează un mod diferit de prezentare a informațiilor, anumite lucruri dintr-o diagramă devin mult mai ușor de identificat decât în alta. De asemenea, este de remarcat faptul că diagrama de comunicare arată mai clar cu ce elemente interacționează fiecare element separat, în timp ce o diagramă de secvență arată mai clar în ce ordine au loc interacțiunile.

Diagrama secvenței

O diagramă de secvență UML arată interacțiunile dintre mai multe obiecte care sunt ordonate în funcție de momentul în care apar. Această diagramă arată interacțiunea ordonată în timp dintre mai multe obiecte. În special, afișează toate obiectele care participă la interacțiune, precum și secvența completă de mesaje schimbate între ele.

Elementele principale în acest caz sunt denumirile diverse obiecte, precum și linii verticale care înfățișează trecerea timpului și dreptunghiuri reprezentând activitatea unui anumit obiect sau îndeplinirea unei anumite funcții.

Diagrama de cooperare

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

Deoarece diagramele de secvență și de comunicare sunt pur și simplu vederi diferite ale acelorași proceduri, Rational Rose oferă posibilitatea de a crea o diagramă 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 Limbajul UML, care sunt un tip de diagramă de activitate și includ atât elementele secvenței, cât și constructele fluxului de control.

Este de remarcat faptul că acest format combină diagrama de colaborare și secvență, care oferă posibilitatea de a lua în considerare interacțiunea dintre mai multe obiecte din sistem care se formează din puncte de vedere diferite.

Diagrama de timp

Reprezintă o versiune alternativă a unei diagrame de secvență care demonstrează în mod explicit schimbarea stării de-a lungul unei linii de salvare pe o anumită scară de timp. Poate fi destul de util în aplicatii diverseîn timp real.

Care sunt avantajele?

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 sunt apropiate semantic de metodele de programare în tot felul de limbaje moderne orientate pe obiecte.
Cu ajutorul a acestei limbi un sistem poate fi descris din aproape orice punct de vedere posibil și în același mod sunt descrise diverse aspecte ale comportamentului său.
Toate diagramele sunt relativ ușor de citit chiar și după o introducere relativ rapidă în sintaxa acesteia.
UML vă permite să extindeți și, de asemenea, să introduceți propriile stereotipuri grafice și text, ceea ce promovează utilizarea acestuia nu numai în ingineria software.
Limba e destul răspândită, și se dezvoltă, de asemenea, destul de activ.

Defecte

În ciuda faptului că construirea diagramelor UML are o mulțime de avantaje, acestea sunt adesea criticate pentru următoarele dezavantaje:

Redundanţă. În marea majoritate a cazurilor, criticii spun că UML este prea mare și complex, iar acest lucru este adesea nejustificat. Include destul de multe desene și diagrame redundante sau practic inutile, iar de cele mai multe ori astfel de critici sunt îndreptate către cea de-a doua versiune, nu către prima, deoarece revizuirile mai noi conțin 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, nu are rigiditatea care este inerentă limbilor definite cu precizie prin tehnici 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. Descrierile imprecise ale limbajului în sine afectează atât utilizatorii, cât și furnizorii de instrumente, ducând în cele din urmă la incompatibilitatea instrumentelor din cauza modului unic de tratare a diferitelor specificații.
Probleme în procesul de implementare și învățare. 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 de lucru în sine, adică codul este proiectul. Conform acestei opinii, este nevoie să se dezvolte mai mult mod eficient software de scriere. UML este apreciat în mod obișnuit în abordările care compilează modele pentru a regenera executabil sau cod sursă. 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 la ceea ce instrumentul de interpretare UML poate ghici 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 o altă ieșire. Ca în oricare sisteme standard notație, UML poate reprezenta unele sisteme mai eficient și mai concis decât altele. Astfel, dezvoltatorul este mai înclinat către acele soluții care sunt mai confortabile pentru împletirea tuturor punctele forte UML, precum și alte limbaje de programare. Această problemă este mai evidentă dacă limbajul de dezvoltare nu se conformează principiilor de bază ale ortodoxiei orientate pe obiecte, adică nu încearcă să funcționeze în conformitate cu principiile OOP.
Încearcă să fie universal. UML este un limbaj de modelare de uz general care încearcă să fie compatibil cu orice limbaj de procesare disponibil în prezent. În contextul unui proiect dat, pentru ca echipa de proiectare să atingă scopul final, este necesar să se selecteze caracteristicile aplicabile ale limbajului respectiv. Pe langa asta moduri posibile limitările sferei de aplicare a UML într-un anumit domeniu sunt supuse unui formalism care nu este pe deplin articulat și care este el însuși supus criticii.

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

Majoritatea metodelor existente de analiză și proiectare orientate pe obiecte (OOAD) includ atât un limbaj de modelare, cât și o descriere a procesului de modelare. Limbajul de modelare este o notație (în mare parte grafică) care este folosită de o metodă pentru a descrie proiecte.

Notaţie este o colecție de obiecte grafice care sunt folosite în modele; este sintaxa limbajului de modelare. De exemplu, notația diagramei de clasă definește modul în care sunt reprezentate elemente și concepte precum clasă, asociere și multiplicitate.

Proces este o descriere a pașilor care trebuie urmați la dezvoltarea unui proiect.

Limbajul de modelare unificat UML(Unified Modeling Language) este succesorul acelei generații de metode OOAP care a apărut la sfârșitul anilor 80 și începutul anilor 90.

Limbajul UML este un limbaj de modelare vizuală de uz general, care este conceput pentru specificarea, vizualizarea, proiectarea și documentarea componentelor software, proceselor de afaceri și a altor sisteme. Limbajul UML este, în același timp, un instrument de modelare simplu și puternic, care poate fi utilizat eficient pentru a construi modele conceptuale, logice și grafice ale sistemelor complexe pentru o mare varietate de scopuri.

Utilizarea constructivă a limbajului UML se bazează pe înțelegerea principiilor generale ale modelării sistemelor complexe și, în special, a caracteristicilor procesului de proiectare orientată pe obiecte (OOP). Alegerea mijloacelor expresive pentru construirea modelelor de sisteme complexe predetermina sarcinile care pot fi rezolvate folosind aceste modele. În același timp, unul dintre principiile de bază pentru construirea modelelor de sisteme complexe este principiul abstracției, care prescrie includerea în model numai a acelor aspecte ale sistemului proiectat care sunt direct legate de îndeplinirea funcțiilor sale de către sistem sau de scopul propus. . În acest caz, toate detaliile minore sunt omise pentru a nu complica excesiv procesul de analiză și cercetare a modelului rezultat.

Un alt principiu pentru construirea modelelor de sisteme complexe este principiul multimodelului. Acest principiu este o afirmație că niciun model nu poate descrie în mod adecvat diferitele aspecte ale unui sistem complex. În legătură cu metodologia OOP, aceasta înseamnă că un model destul de complet al unui sistem complex permite un număr de vederi interconectate, fiecare dintre acestea reflectând în mod adecvat un anumit aspect al comportamentului sau structurii sistemului. În același timp, cele mai generale reprezentări ale unui sistem complex sunt considerate a fi reprezentări statice și dinamice, care la rândul lor pot fi subdivizate în alte reprezentări mai specifice.) fenomenul unui sistem complex constă tocmai în faptul că nicio reprezentare unică nu există. este suficient pentru a exprima în mod adecvat toate caracteristicile sistemului modelat.

Un alt principiu al analizei sistemelor aplicate este principiul construcției ierarhice a modelelor de sisteme complexe. Acest principiu prescrie luarea în considerare a procesului de construire a unui model la diferite niveluri de abstractizare sau de detaliu în cadrul unor idei fixe. În acest caz, modelul inițial sau inițial al unui sistem complex are cea mai generală reprezentare (meta-reprezentare). Un astfel de model este construit în stadiul inițial de proiectare și este posibil să nu conțină multe detalii și aspecte ale sistemului care se modelează.

Crearea UML a început de fapt la sfârșitul anului 1994, când Gradi B uch și James Rumbaugh a început să lucreze la combinarea metodelor Booch și OMT (Tehnica de modelare a obiectelor) sub auspiciile Rational Software. Până la sfârșitul anului 1995, ei creaseră prima specificație a unei metode unificate, pe care o numeau Unified Method, versiunea 0.8. Apoi, în 1995, li s-a alăturat creatorul metodei OOSE (Object-Oriented Software Engineering). Ivar Jacobson. Astfel, UML este o unificare și o unificare directă Metodele Booch, Rambo și Jacobson , cu toate acestea, le completează cu noi capabilități.

Principalele obiective în dezvoltarea UML au fost:

– să ofere utilizatorilor un limbaj de modelare vizuală expresiv, gata de utilizat, care le permite să dezvolte și să partajeze modele semnificative;

– să ofere mecanisme de extensibilitate și specializare pentru extinderea conceptelor de bază;

– asigurarea independenței față de limbaje de programare specifice și procese de dezvoltare;

– să ofere o bază formală pentru înțelegerea acestui limbaj de modelare (limbajul trebuie să fie atât precis, cât și ușor de înțeles, fără formalism inutil);

– stimularea creșterii pieței de instrumente orientate pe obiect;

– să integreze cea mai bună experiență practică.

Limbajul UML se află în proces de standardizare de către OMG (Object Management Group), organizația de standardizare pentru metode și tehnologii orientate pe obiecte, iar acum a fost adoptat ca limbaj de modelare standard și a primit sprijin pe scară largă în industria software.

Limbajul UML adoptat de aproape toate marile companii producătoare de software (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase etc.). În plus, aproape toți producătorii globali de instrumente CASE, pe lângă Rational Software (Rational Rose), acceptă UML în produsele lor (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler pentru Visual Basic, Delphi, PowerBuilder etc.). O descriere completă a UML poate fi găsită la http://www.omg.urg, http://www.rational.com și http://uml.shl.com. O descriere a UML în limba rusă este cuprinsă în cartea lui M. Fowler și K. Scott în prezentarea următoare, terminologia limbii corespunde acestei traduceri;

Creatorii UML îl prezintă ca un limbaj pentru definirea, reprezentarea, proiectarea și documentarea sistemelor software, organizaționale, economice, tehnice etc.

UML conține un set standard de diagrame și notații de o mare varietate de tipuri.

Diagrama în UML este o reprezentare grafică a unui set de elemente, cel mai adesea reprezentat ca un graf conectat cu vârfuri (entități) și muchii (relații). Diagramele sunt desenate pentru a vizualiza un sistem din perspective diferite.

Diagramă– într-un sens, una dintre proiecțiile sistemului. De regulă, cu excepția celor mai banale cazuri, diagramele oferă o vedere condensată a elementelor care alcătuiesc sistemul. Același element poate fi prezent în toate diagramele, sau doar în câteva (opțiunea cea mai comună), sau nu este prezent în niciuna (foarte rar).

În teorie, diagramele pot conține orice combinație de entități și relații. În practică, însă, se utilizează un număr relativ mic de combinații standard, corespunzătoare celor mai comune cinci tipuri care alcătuiesc arhitectura unui sistem software.

În UML se disting următoarele: tipuri de diagrame:

– diagrame de caz de utilizare(diagrame de caz de utilizare) – pentru modelarea proceselor de afaceri ale organizației (cerințe de sistem);

– diagrame de clasă(diagrame de clasă) – pentru modelarea structurii statice a claselor de sistem și a conexiunilor dintre acestea. Astfel de diagrame arată clase, interfețe, obiecte și colaborări, precum și relațiile lor. La modelarea sistemelor orientate pe obiecte, acest tip de diagramă este folosit cel mai des. Diagramele de clasă corespund vederii statice a sistemului din punct de vedere al proiectării;

– diagrame de comportament ale sistemului(diagrame de comportament);

– diagrame de interacțiune(diagrame de interacțiune) – pentru modelarea procesului de mesagerie între obiecte. Există două tipuri de diagrame de interacțiune: diagrame de succesiune(diagrame secvențe) și diagrame cooperative(diagrame de colaborare). Diagramele de interacțiune reprezintă relații între obiecte; arată, în special, mesajele pe care obiectele le pot schimba. Diagramele de interacțiune se referă la vizualizarea dinamică a sistemului. În același timp, diagramele de secvență reflectă ordonarea temporală a mesajelor, iar diagramele de cooperare reflectă organizarea structurală a obiectelor care fac schimb de mesaje. Aceste diagrame sunt izomorfe, adică pot fi transformate una în alta;

– diagrame de stare(diagrame statechart) – pentru modelarea comportamentului obiectelor de sistem în timpul trecerii de la o stare la alta. Ele reprezintă un automat care include stări, tranziții, evenimente și tipuri de acțiuni. Diagramele de stare se referă la vederea dinamică a unui sistem; Ele sunt deosebit de importante atunci când se modelează comportamentul unei interfețe, clase sau colaborări. Acestea se concentrează pe comportamentul unui obiect în funcție de succesiunea evenimentelor, ceea ce este foarte util pentru modelarea sistemelor reactive;

– diagrame de activitate(diagrame de activitate) - pentru modelarea comportamentului sistemului în cadrul diferitelor cazuri de utilizare sau activități de modelare. Acesta este un caz special al unei diagrame de stare; reprezintă tranzițiile fluxului de control de la o activitate la alta în cadrul sistemului. Diagramele de activitate se referă la vizualizarea dinamică a sistemului; acestea sunt cele mai importante atunci când se modelează funcționarea acestuia și reflectă fluxul de control între obiecte;

– diagrame de implementare: diagrame ale componentelor(diagrame componente) – pentru modelarea ierarhiei componentelor (subsistemelor) sistemului; diagrame de amplasare(diagrame de implementare) – pentru modelarea arhitecturii fizice a sistemului. O diagramă de componente arată organizarea unei colecții de componente și dependențele care există între ele. Diagramele componente se referă la o vedere statică a unui sistem din perspectiva implementării. Acestea pot fi legate de diagramele de clasă, deoarece o componentă este de obicei mapată la una sau mai multe clase, interfețe sau colaborări

Limbajele de modelare orientate pe obiecte au apărut de la mijlocul anilor 70 până la sfârșitul anilor 80, când cercetătorii, confruntați cu nevoia de a ține cont de noile capacități ale limbajelor de programare orientate pe obiecte și de cerințele aplicațiilor din ce în ce mai complexe, au fost forțați pentru a începe dezvoltarea diferitelor abordări alternative ale analizei și proiectării.

Din 1989 până în 1994, numărul diferitelor metode orientate pe obiect a crescut de la zece la mai mult de cincizeci. Cu toate acestea, mulți utilizatori au avut dificultăți în a alege un limbaj de modelare care se potrivea pe deplin nevoilor lor, ceea ce a dus la așa-numitele „războaie de metode”. În urma acestor războaie, a apărut o nouă generație de metode, printre care limbile au căpătat o importanță deosebită Booch, creat Grady Boochum (Grady Booch) OOSE(Inginerie software orientată pe obiecte), dezvoltat de Ivar Jacobson (Ivar Jacobson) și OMT(Tehnica de modelare a obiectelor), scris de James Rumbaugh (James Rumbaugh) În plus, ar trebui menționate limbile Fusion, Schlaer-Mellor(Shlaer-Mellor) și Koada-Yordona(Coad-Yourdon). Fiecare dintre aceste metode poate fi considerată complet holistică și completă, deși fiecare dintre ele are nu numai puncte forte, ci și puncte slabe.

Capacitățile expresive ale metodei Booch sunt deosebit de importante în etapele de proiectare și construcție a modelului. OOSE este excelent pentru analiza și formularea cerințelor, precum și pentru design la nivel înalt. OMT-2 s-a dovedit a fi deosebit de util pentru analiza și dezvoltarea sistemelor informaționale axate pe prelucrarea unor volume mari de date.

O masă critică de idei noi a început să se formeze pe la mijlocul anilor '90, când Grady Butch(Rational Software Corporation) Ivar Jacobson(Obiectiv) și James Rumbaugh(General Electric) a făcut o încercare de a-și combina metodele, care au primit deja recunoașterea la nivel mondial ca fiind cele mai promițătoare în acest domeniu. Fiind principalii autori ai limbilor Booch, OOSE și OMT, partenerii au încercat să creeze unul nou, limbaj de modelare unificatși s-au ghidat după trei considerații.

În primul rând, toate cele trei metode, indiferent de dorințele dezvoltatorilor, s-au dezvoltat deja în direcția opusă. Era logic să continuăm această evoluție împreună, mai degrabă decât separat, ceea ce ar ajuta la eliminarea diferențelor nedorite și a neplăcerilor rezultate pentru utilizatori în viitor.

În al doilea rând, prin unificarea metodelor, ar fi mai ușor să aducem stabilitate pe piața instrumentelor de modelare orientată pe obiecte, permițând tuturor proiectelor să se bazeze pe un singur limbaj matur și permițând creatorilor de instrumente să se concentreze pe activități mai productive.

În cele din urmă, a fost de presupus că o astfel de cooperare va duce la îmbunătățiri în toate cele trei metode și va oferi o soluție la probleme pentru care oricare dintre ele, luată separat, nu era prea potrivită.

– modelați sisteme întregi, de la concept la artefact executabil, folosind metode orientate pe obiect;

– să rezolve problema scalabilității, care este inerentă sistemelor complexe concepute pentru a îndeplini sarcini critice;

– creați un limbaj de modelare care poate fi folosit nu numai de oameni, ci și de computere.

Inventarea unui limbaj pentru analiza și proiectarea orientate pe obiecte nu este mult diferită de inventarea unui limbaj de programare. În primul rând, a fost necesar să se limiteze problema. Ar trebui limbajul să includă capacitatea de a specifica cerințe? Ar trebui un limbaj să permită programarea vizuală? În al doilea rând, a fost necesar să se găsească un echilibru între puterea expresivă și simplitate. Un limbaj prea simplu ar limita gama de probleme pe care le poate rezolva, în timp ce un limbaj prea complex ar putea copleși un dezvoltator neexperimentat. În plus, la combinarea metodelor existente, a fost necesar să se țină cont de disponibilitatea produselor deja dezvoltate folosindu-le. Efectuarea prea multor modificări ar putea înstrăina utilizatorii existenți și, rezistând dezvoltării limbajului, autorii ar pierde oportunitatea de a atrage noi utilizatori și de a face limbajul mai simplu și mai ușor de utilizat. Când au creat UML, dezvoltatorii au încercat să găsească solutie optima aceste probleme.

Crearea UML a început oficial în octombrie 1994, când Rumbaugh s-a mutat la Rational Software, unde lucra Butch. Scopul inițial a fost de a combina metodele Booch și HMT. Primul proces versiunea 0.8 a Metodei unificate(Metoda unificată), așa cum era numită atunci, a apărut în octombrie 1995 . În această perioadă, Jacobson sa alăturat Rational și proiectul UML a fost extins pentru a include OOSE. Ca urmare a eforturilor comune în iunie 1996 a iesit Versiunea UML 0.9. De-a lungul anului, creatorii au colectat feedback de la marile companii care lucrează în domeniul designului de software. În acest timp, a devenit clar că majoritatea acestor companii au considerat că UML este un limbaj de importanță strategică pentru afacerea lor. Ca urmare, a fost înființat Consorțiul UML, care includea organizații dornice să ofere resurse pentru munca menită să creeze o definiție completă a UML.

Versiunea lingvistică 1.0 a fost rezultatul unui efort comun dintre Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments și Unisys. UML 1.0 s-a dovedit a fi un limbaj bine definit, expresiv, puternic aplicabil unei game largi de probleme. În ianuarie 1997, a fost depusă la Object Management Group (OMG) pentru un concurs de creare a unui limbaj de modelare standard.

Între ianuarie și iunie 1997, consorțiul UML sa extins pentru a include practic toate companiile care au răspuns la apelul OMG și anume: Andersen Consulting, Ericsson, ObjecTime Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software și Taskon. Pentru a oficializa specificațiile UML și a coordona munca cu alte grupuri de standarde, a fost format un grup semantic sub conducerea lui Cris Kobryn de la MCI Systemhouse și Ed Eykholt de la Rational. O versiune revizuită a UML (1.1) a fost din nou transmisă OMG în iulie 1997. În septembrie, versiunea a fost aprobată la ședințele Grupului de analiză și proiectare și ale Comitetului de arhitectură OMG, iar pe 14 noiembrie 1997, adoptată ca standard la adunarea generală a tuturor membrilor OMG.

Lucrări suplimentare privind dezvoltarea UML au fost efectuate de către Revision Task Force (RTF) al OMG sub conducerea lui Chris Kobrin. ÎN iunie 1998 UML 1.2 a fost lansat și toamna anului 1998– UML 1.3.

Limbajul de modelare UML

UML(limbaj de modelare unificat) este un limbaj de descriere grafică pentru modelarea obiectelor în domeniul dezvoltării software. Folosește notația grafică pentru a crea un model al sistemului. Acest limbaj a fost creat pentru definirea, vizualizarea, proiectarea și documentarea sistemelor software și este, de asemenea, utilizat pentru modelarea proceselor de afaceri și proiectarea sistemului.

Descrierea limbajului de modelare unificat UML

O scurtă istorie a UML (Creatori: Grady Butch, Ivar JacobsonŞi James Rumbaugh)

Modelul conceptual al UML (modelul conceptual include: blocurile de bază ale limbajului; reguli pentru combinarea lor; unele mecanisme comune întregului limbaj)

Tipuri de diagrame pentru modelare:

Diagrame de cazuri de utilizare (descriu funcționalitatea sistemului sau ceea ce ar trebui să facă sistemul)

Diagrame de clasă (folosite pentru a reprezenta structura statică a unui model de sistem în terminologia claselor de programare orientată pe obiecte; astfel de diagrame pot reflecta diverse relații între entități de domeniu individuale, cum ar fi obiecte și subsisteme, precum și să descrie structura lor internă și tipurile de relații)

Diagrame de interacțiune (descriu interacțiunea dintre obiectele dintr-un sistem și sunt împărțite în două tipuri principale de diagrame: diagrame de secvență și diagrame de cooperare)

Diagrame de stări (folosite pentru a descrie toate stările posibile ale unei instanțe a unei anumite clase și secvențele posibile ale tranzițiilor acesteia de la o stare la alta, adică modelează toate modificările stărilor unui obiect ca răspuns la influențele externe)

Diagrame de activitate (utilizate pentru a modela procesul de realizare a activităților)

Diagrame de implementare (servesc pentru a reprezenta componentele sistemului și se referă la modelul fizic al acestuia)

Diagrame componente (descrie caracteristicile reprezentării fizice a sistemului și vă permite să determinați arhitectura sistemului în curs de dezvoltare prin stabilirea dependențelor între componentele software, care pot fi cod sursă și cod executabil)

Diagramele de plasare (reflectează relațiile fizice dintre componentele software și hardware ale sistemului și sunt, de asemenea, utilizate pentru a descrie rutele de mișcare a obiectelor într-un sistem distribuit)

Toate diagramele UML pot fi împărțite î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 subiectului, zona soluției 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 concepută pentru a răspunde la întrebarea principală de modelare: ce face sistemul în lumea exterioară?

O diagramă de utilizare utilizează două tipuri de entități de bază: cazurile de utilizare 1 și actorii 2, între care se stabilesc următoarele tipuri de relații de bază:

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

O diagramă de utilizare, ca orice altă diagramă, poate conține comentarii 7 . Mai mult, acest lucru este foarte recomandat pentru a îmbunătăți lizibilitatea diagramelor.

Elementele principale de notație utilizate într-o diagramă de utilizare sunt prezentate mai jos. O descriere detaliată este dată în secțiunea 2.2.

1.5.2. Diagrama de clasă

Diagrama de clasă(diagrama de clasă) este modalitatea principală de a descrie structura unui sistem.

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).

O diagramă de clasă utilizează un tip de bază de entitate: 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 de relații de bază:

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

Unele dintre notațiile utilizate într-o diagramă de clasă sunt prezentate mai jos. O descriere detaliată este dată în capitolul 3.

1.5.3. Diagrama mașinii

Diagrama mașinii(diagrama mașinii de stări) este una dintre modalitățile de a descrie comportamentul în detaliu în UML bazat pe identificarea explicită a stărilor și descrierea tranzițiilor între stări.

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

Pe o diagramă automată, se utilizează un tip principal de entitate - stările 1 și un tip de relație - tranzițiile 2, dar pentru ambele sunt definite multe varietăți, cazuri speciale și notații suplimentare. Nu are rost să le enumerăm pe toate într-o recenzie introductivă.

O descriere detaliată a tuturor variațiilor diagramelor automate este dată în secțiunea 4.2, iar figura următoare arată 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 specificarea fluxurilor de control și a fluxurilor de date.

O diagramă de activitate este o altă modalitate de a descrie un comportament care amintește vizual de o diagramă de flux de algoritm 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 pentru descrierea comportamentului sistemului.

Diagrama de activitate folosește un tip principal de entitate - 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 de fapt nu sunt, ci sunt 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. Principalele elemente de notație utilizate într-o diagramă de activitate sunt prezentate mai jos.

1.5.5. Diagrama secvenței

Diagrama secvenței(diagrama secvenței) este o modalitate de a descrie comportamentul unui sistem bazat pe indicarea 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 important lucru în timpul execuției este transmiterea de mesaje între obiectele care comunică. Este secvența de trimitere a mesajelor care este afișată în această diagramă, de unde și numele.

O diagramă de secvență folosește un tip principal de entitate - instanțe de clasificatori care interacționează 1 (în principal clase, componente și actori) și un tip de relație - conexiuni 2 de-a lungul cărora sunt schimbate mesajele 3. Există mai multe moduri de a trimite mesaje, care în notație grafică diferă prin tipul de săgeată corespunzător relației.

Un aspect important al unei diagrame secvențe este acela de a arăta în mod clar trecerea timpului. Spre deosebire de alte tipuri de diagrame, cu excepția poate diagramelor de sincronizare, într-o diagramă de secvență nu este doar prezența link-uri graficeîntre elemente, dar și poziția relativă a elementelor pe diagramă. Și anume, se presupune 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.

Următoarea figură prezintă notația de bază utilizată într-o diagramă de secvență. Pentru a desemna obiectele care interacționează în sine, se folosește o notație standard - un dreptunghi cu numele instanței clasificatorului. Linie punctată, care iese din ea, se numește linia de salvare 4. Aceasta nu este o reprezentare a unei relații în model, ci un comentariu grafic menit să ghideze cititorul diagramei în direcția corectă. Figurile sub formă de dungi înguste suprapuse pe linia vieții nu sunt, de asemenea, imagini ale entităților simulate. Acesta este un comentariu grafic care arată perioadele de timp în care obiectul deține fluxul de control (ocurență de execuție) 5 sau, cu alte cuvinte, are loc activarea obiectului. Pașii 6 de fragment combinați permit diagramei de secvență să reflecte aspectele algoritmice ale protocolului de interacțiune. Pentru alte detalii despre notarea diagramei secvențe, consultați Capitolul 4.

1.5.6. Diagrama de comunicare

Diagrama de comunicare(diagrama de comunicare) este un mod de a descrie comportamentul care este echivalent din punct de vedere semantic cu o diagramă de secvență.

De fapt, aceasta este aceeași descriere a secvenței schimbului de mesaje a instanțelor care interacționează ale clasificatorilor, exprimată doar de alții 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ță, este utilizat un tip principal de entitate - instanțe de clasificatori interacționați 1 și un tip de relație - conexiunile 2.

Totuși, aici accentul nu este pus pe timp, ci pe structura conexiunilor dintre instanțe specifice.

Figura prezintă principalele elemente de notație utilizate într-o diagramă de comunicare. Pentru a desemna obiectele care interacționează în sine, se folosește o notație standard - un dreptunghi cu numele instanței clasificatorului. Poziția relativă a elementelor din diagrama de cooperare nu contează - doar conexiunile (cel mai adesea instanțe de asociere) de-a lungul cărora sunt transmise mesajele 3 sunt importante. Numerotarea zecimală ierarhică este utilizată pentru a afișa ordinea mesajelor în timp.

1.5.7. Diagrama componentelor Diagrama componentelor

(diagrama componentelor) - prezintă relaţiile dintre modulele (logice sau fizice) care alcătuiesc sistemul modelat.

Principalul tip de entități dintr-o diagramă de componente sunt componentele în sine 1, precum și interfețele 2, prin care este indicată relația dintre componente. Următoarele relații se aplică într-o diagramă de componente:
dependențe între componente și interfețe (componenta folosește interfața) 3.

Figura prezintă principalele elemente ale notației utilizate într-o diagramă de componente. 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 conexiunilor elementelor sistemului, arată modul în care acestea sunt localizate fizic pe resursele de calcul în timpul execuției.

Astfel, într-o diagramă de plasare, în comparație cu o diagramă de componente, se adaugă două tipuri de entități: artefactul 1, care este o implementare a componentei 2 și a nodului 3 (poate fi fie un clasificator care descrie tipul de nod, fie o instanță specifică), precum și relația de asociere dintre nodurile 4, arătând că nodurile sunt conectate fizic în timpul rulării.

Figura prezintă principalele elemente ale notației utilizate în diagrama de layout. Pentru a arăta că o entitate este o parte a alteia, fie se aplică o relație de dependență „desfășurare” 5, fie o figură a unei entități este plasată în interiorul unei figuri a altei entități 6 . O descriere detaliată a diagramei este dată în capitolul 3.

11.1. Structura limbajului de modelare unificat

Limbajul de modelare unificat (UML) în momentul prezent este standardul de facto pentru descrierea (documentarea) rezultatelor proiectării și dezvoltării sistemelor orientate pe obiecte. Dezvoltarea UML a început în 1994 de către Grady Booch și James Rumbaugh, care au lucrat la Rational Software. În toamna anului 1995, li s-a alăturat Ivar Jacobson, iar în octombrie a acelui an, a fost lansată o versiune preliminară 0.8 a Metodei unificate. De atunci, au fost lansate mai multe versiuni ale specificației UML, dintre care două au statut de standard internațional:

UML 1.4.2 – „ISO/IEC 19501:2005. Tehnologia de informație. Procesare de distribuție deschisă. Limbajul de modelare unificat (UML). Versiunea 1.4.2” (în engleză „Tehnologia informației. Procesare distribuită deschisă. Limbajul de modelare unificat (UML). Versiunea 1.4.2”);

UML 2.4.1 - „ISO/IEC 19505-1:2012. Tehnologia informației. Object Management Group Unified Modeling Language (OMG UML). Partea 1. Infrastructură” (ing. „Information Technology -- Object Management Group Unified Modeling Language ( OMG). UML) - Partea 1: Infrastructură") și „ISO/IEC 19505-2:2012 Tehnologia informației pentru Grupul de modelare unificată (OMG UML) Partea 2. Suprastructură” (ing. „Tehnologia informației - Obiect”). Management Group Unified Modeling Language (OMG UML) - Partea 2: Suprastructură").

Cea mai recentă specificație a limbii oficiale poate fi găsită la www.omg.org.

Structura generală a UML este prezentată în figura următoare.

Orez. 11.1. Structura UML

11.2. Semantică și sintaxă UML

Semantică - o ramură a lingvisticii care studiază semnificația unităților de limbă, în primul rând cuvintele și frazele sale.

Sintaxă – moduri de combinare a cuvintelor și a formelor lor în fraze și propoziții, combinarea propozițiilor în propoziții complexe, modalități de a crea enunțuri ca parte a unui text.

Astfel, în raport cu UML, semantica și sintaxa determină stilul de prezentare (model building), care combină limbajele naturale și formale pentru a reprezenta conceptele de bază (elementele modelului) și mecanismele de extindere a acestora.

11.3. Notație UML

Notația este o interpretare grafică a semanticii pentru reprezentarea sa vizuală.

UML definește trei tip de entitate :

Structural - o abstractizare care este o reflectare a unui obiect conceptual sau fizic;

Grupare – un element folosit pentru o combinație semantică de elemente de diagramă;

Explicativ (adnotativ) – un comentariu asupra unui element de diagramă.

Următorul tabel arată scurtă descriere principalele entități utilizate în notația grafică și principalele modalități de afișare a acestora.

Tabelul 11.1. Entități

Tip	Nume	Desemnare	Definiție (semantică)
Structural	(clasă)		Un set de obiecte care au o structură și un comportament comun
	(obiect)		O abstractizare a unei entități reale sau imaginare cu granițe conceptuale, personalitate, stare și comportament clar definite. Din punct de vedere UML, obiectele sunt instanțe ale unei clase (instanțe ale unei entități)
	(actor)	Inginer servicii de cale	O entitate externă sistemului care interacționează și utilizează sistemul funcţionalitate pentru a atinge anumite obiective sau a rezolva anumite probleme. Astfel, un actor este o sursă sau un receptor extern de informații
	(caz de utilizare)		Descrierea acțiunilor efectuate de sistem, ceea ce duce la un rezultat semnificativ pentru actor
	(stat)		O descriere a unui moment din viața unei entități în care aceasta satisface o anumită condiție, desfășoară o activitate sau așteaptă să aibă loc un eveniment.
	Cooperare (colaborare)		Descrierea unui set de instanțe de actori, obiecte și interacțiunea acestora în procesul de rezolvare a unei anumite probleme
	(componenta)		Partea fizică a sistemului (fișier), inclusiv modulele de sistem care asigură implementarea unui set consistent de interfețe
	(interfata)	iCalcul	Un set de operațiuni care definește un serviciu (set de servicii) furnizat de o clasă sau componentă
	(nodul)		Partea fizică a sistemului (calculator, imprimantă etc.) care oferă resurse pentru a rezolva o problemă
Gruparea	(pachet)		Mecanism general de grupare a elementelor. Spre deosebire de o componentă, un pachet este un concept pur conceptual (abstract). Cazurile speciale ale unui pachet sunt sistemul și modelul
	(fragment)		Zona de interacțiune specifică dintre instanțele actorului și obiectele
	(partiție de activitate)		Un grup de operațiuni (zona de responsabilitate) efectuate de o entitate (actor, obiect, componentă, nod etc.)
	(regiune de activitate întreruptibilă)		Un grup de operațiuni, a căror secvență normală de execuție poate fi întreruptă ca urmare a apariției unei situații neobișnuite
Explicativ	Nota (comentariu)		Comentariu pentru element. Se atașează elementului comentat cu o linie întreruptă

Unele surse, în special [,], identifică, de asemenea, entități comportamentale interacțiuniŞi mașini cu stări finite, dar din punct de vedere logic ele ar trebui clasificate ca diagrame.

Unele dintre entitățile de mai sus, în conformitate cu implică descrierea lor detaliată în diagramele de descompunere. Pe diagrama de nivel superior, acestea sunt marcate cu o pictogramă sau etichetă specială.

Următorul tabel oferă o descriere a tuturor tipurilor relaţii UML folosit în diagrame pentru a indica relațiile dintre entități.

Tabelul 11.3. Relaţie

Nume	Desemnare	Definiție (semantică)
Asociere		O relație care descrie o conexiune semnificativă între două sau mai multe entități. Cel mai general tip de relație
Agregare		Un subtip de asociere care descrie relația „parte” – „întreg”, în care „partea” poate exista separat de „întreg”. Rombul este indicat din partea „întregii”. Relația este specificată numai între entități de același tip
Compoziţie		Un subtip de agregare în care „părțile” nu pot exista separat de „întregul”. De regulă, „părțile” sunt create și distruse simultan cu „întregul”
Dependenţă		O relație între două entități în care o schimbare într-o entitate (independentă) poate afecta starea sau comportamentul celeilalte entități (dependent). Partea săgeată indică o entitate independentă
Generalizare		Relația dintre o entitate generalizată (strămoș, părinte) și o entitate specializată (descendent, fiică). Triunghiul este indicat din partea părintelui. Relația este specificată numai între entități de același tip
Realizare		O relație între entități în care o entitate specifică o acțiune pe care o altă entitate se angajează să o efectueze. Relațiile sunt utilizate în două cazuri: între interfețe și clase (sau componente), între cazuri de utilizare și colaborări. Partea săgeată indică entitatea care definește acțiunea (interfață sau caz de utilizare)

Pentru asociere, se pot specifica agregarea și compoziția multiplicitate (ing. multiplicitate), care caracterizează numărul total de instanțe ale entităților care participă la relație. De obicei, este indicat pe fiecare parte a relației lângă entitatea corespunzătoare. Multiplicitatea poate fi indicată în următoarele moduri:

- * – orice număr de copii, inclusiv niciunul;

Număr întreg nenegativ – multiplicitatea este strict fixă și egală cu numărul specificat (de exemplu: 1, 2 sau 5);

Interval de numere întregi nenegative „primul număr.. al doilea număr” (de exemplu: 1..5, 2..10 sau 0..5);

O gamă de numere de la o anumită valoare inițială până la un „primul număr..*” final arbitrar (de exemplu: 1..*, 5..* sau 0..*);

Listarea numerelor întregi nenegative și a intervalelor separate prin virgule (de exemplu: 1, 3..5, 10, 15..*).

Dacă multiplicitatea nu este specificată, atunci valoarea ei se presupune a fi 1. Multiplicitatea instanțelor de entitate care participă la dependență, generalizare și implementare este întotdeauna presupusă a fi 1.

Următorul tabel oferă o descriere mecanisme de expansiune , folosit pentru a clarifica semantica entităților și a relațiilor. În general, mecanismul de extindere este un șir de text cuprins între paranteze sau ghilimele.

Tabelul 11.4. Mecanisme de expansiune

Nume	Desemnare	Definiție (semantică)
Stereotip (stereotip)	« »	O desemnare care specifică semantica unui element de notație (de exemplu: o dependență cu stereotipul „include” este considerată o relație de includere, iar o clasă cu stereotipul „limită” este o clasă limită)
Stare de gardă (condiția de gardă)		Condiție booleană (de exemplu: sau [identificare finalizată])
Prescripţie (constrângere)	{ }	O regulă care limitează semantica unui element de model (de exemplu, (timp de execuție mai mic de 10 ms))
Valoare marcată (valoare marcată)	{ }	Proprietate nouă sau de clarificare a unui element de notație (de exemplu: (versiunea = 3.2))

Pe lângă stereotipurile indicate ca șir de text între ghilimele, stereotipurile grafice pot fi folosite în diagrame. Figura următoare prezintă exemple de afișaj standard și stereotip.


a) denumire standard		b) denumire standard cu stereotip de text		c) stereotip grafic

Orez. 11.2. Exemple de afișare a clasei standard și stereotip

Diagramă reprezintă o grupare de elemente de notație pentru a afișa unele aspecte ale dezvoltate sistem informatic. Diagramele sunt de obicei un graf conectat în care entitățile sunt vârfuri și relațiile sunt arce. Următorul tabel oferă scurtă descriere Diagramele UML.

Tabelul 11.5. Diagrame

Diagramă			Scop
				după gradul de implementare fizică	prin afișarea dinamicii	după aspectul afișat
(caz de utilizare)			Afișează funcțiile sistemului, interacțiunile dintre actori și funcții	Logic	Static	Funcţional
(clasă)			Afișează un set de clase, interfețe și relații dintre ele	logic sau fizic	Static	Funcțional și informațional
(pachet)			Afișează un set de pachete și relațiile dintre ele	logic sau fizic	Static	Componentă
Comportamente (comportament)	(mașină de stat)		Afișează stările unei entități și tranzițiile între ele în timpul ciclului său de viață	Logic	Dinamic	Comportamentală
	(activitate)		Afișează procesele de afaceri din sistem (descrierea algoritmilor de comportament)
	Interacțiuni (interacţiune)	(secvenţă)	Afișează secvența mesajului care trece între obiecte și actori
		(comunicare)	Similar cu o diagramă de secvență, dar accentul este pus pe structura interacțiunilor dintre obiecte
Implementări (implementare)	(componenta)		Afișează componentele sistemului (programe, biblioteci, tabele etc.) și conexiunile dintre ele	Fizic	Static	Componentă
	desfășurare		Afișează amplasarea componentelor pe nodurile rețelei, precum și configurația acesteia

Standardul UML 2.x definește și diagrame suplimentare, foarte specializate:

Diagrama obiect - asemănătoare, dar obiectele sunt afișate în loc de clase;

Diagrama temporală – descrie starea unui obiect în timp;

Diagrama structurii compozite - descrie porturile (inclusiv interfețele) unei clase pentru interacțiunea cu alte clase;

Diagrama de profil - similară cu o descriere a claselor incluse în acestea;

Diagrama de prezentare a interacțiunii - similară, dar cu fragmente de interacțiune ascunse (fragmente etichetate ref). Reprezintă unul contextual (conceptual), ale cărui elemente vor fi specificate pe diagrame de descompunere separate.

În scopul unei reprezentări conceptuale lărgite a arhitecturii interne a sistemului, majoritatea în timpul construcției permite utilizarea stereotipurilor grafice stabilite pentru așa-numitele. O astfel de diagramă se numește 1, dar nu aparține listei de diagrame definite de standardul UML.

Când se dezvoltă un model separat al unui sistem, se construiesc mai multe tipuri de diagrame. Mai mult, atunci când se dezvoltă un model al unui sistem complex, de regulă, se construiesc mai multe diagrame de același tip. În același timp, nu trebuie să creați tipuri separate de diagrame dacă nu este necesar. De exemplu, diagramele și sunt interschimbabile sunt construite numai pentru obiecte cu comportament complex. Următorul tabel oferă recomandări cu privire la necesitatea dezvoltării (clarificării) diagramelor pentru modelele de sistem.

Tabelul 11.6. Relația dintre modele și diagrame

Tabelul de mai jos nu prezintă un model de testare, deoarece, ca parte a construcției sale, diagramele nu sunt dezvoltate, ci verificate (testate) pentru completitudine și coerență.

Unele dintre diagrame după construirea lor necesită dezvoltare și clarificare ca parte a dezvoltării următorului model (proces tehnologic). Deci, de exemplu, acestea ar trebui clarificate în timpul dezvoltării. În modele.

4. Definiți conceptul " ".

O diagramă UML este un limbaj de descriere grafică specializat, conceput pentru modelarea obiectelor în dezvoltarea diferitelor programe software. Limbajul 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 cod separat pe baza acestuia.

De ce este nevoie?

Cu UML, dezvoltatorii de software pot asigura acordul complet în notația grafică folosită pentru a reprezenta concepte comune precum: componentă, generic, clasă, comportament și agregare. Datorită acestui fapt, se obține un grad mai mare de concentrare pe arhitectură și design.

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

Diagrama de clasă

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 furnizează 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

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

Diagrama structurii compozite/compozite

Este demn de remarcat faptul că vederile de clasă UML și diagrama structurii compozite pot fi utilizate simultan.

Diagrama de implementare

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

Diagrama obiectului

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

Diagrama pachetului

Diagrama de activitate

O diagramă de activitate UML descrie descompunerea unei activități specifice în mai multe părți componente. În acest caz, conceptul de „activitate” este specificarea unui anumit comportament executabil sub formă de execuție paralelă, precum și execuție secvențială coordonată a diferitelor elemente subordonate - tipuri imbricate de activități și diverse acțiuni, unite de fluxuri care merg de la ieșiri. a unui anumit nod la intrările altuia.

Diagramele de activitate UML sunt adesea folosite pentru a modela diferite procese de afaceri, calcule paralele și secvențiale. Printre altele, ele simulează tot felul de proceduri tehnologice.

Diagrama mașinii

Acest tip este numit și puțin diferit - diagrama de stare UML. Are o mașină cu stări finite prezentată cu stări simple și compuse, precum și tranziții.

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

Folosiți diagrame de caz

Dacă o diagramă de caz de utilizare UML este utilizată în procesul 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 disciplină diferite concepte care se referă la o descriere detaliată a funcționalității unui sistem dat.

Comunicatii

O diagramă de comunicare, la fel ca o diagramă de secvență UML, este tranzitivă, adică exprimă interacțiunea, dar în același timp o demonstrează în moduri diferite și, dacă este necesar, poate fi convertită de la una în alta cu gradul de acuratețe necesar. .

În cea mai mare parte, aceste diagrame arată exact aceleași informații pe care ni le oferă o diagramă de secvență, dar deoarece utilizează un mod diferit de prezentare a informațiilor, anumite lucruri dintr-o diagramă devin mult mai ușor de identificat 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 au loc interacțiunile.

Diagrama secvenței

Elementele principale în acest caz sunt desemnările diferitelor obiecte, precum și liniile verticale care descriu trecerea timpului și dreptunghiurile reprezentând activitatea unui anumit obiect sau îndeplinirea unei anumite funcții.

Diagrama de cooperare

Diagrame de prezentare a interacțiunii

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

Diagrama de timp

Care sunt avantajele?

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 sunt apropiate semantic de metodele de programare în tot felul de limbaje moderne orientate pe obiecte.
Folosind acest limbaj, un sistem poate fi descris din aproape orice punct de vedere posibil și diferite aspecte ale comportamentului său sunt descrise în același mod.
Toate diagramele sunt relativ ușor de citit chiar și după o introducere relativ rapidă în sintaxa acesteia.
UML vă permite să extindeți și, de asemenea, să introduceți propriile stereotipuri grafice și text, ceea ce promovează utilizarea acestuia nu numai în ingineria software.
Limba a devenit destul de răspândită și se dezvoltă, de asemenea, destul de activ.

Defecte

În ciuda faptului că construirea diagramelor UML are o mulțime de avantaje, acestea sunt adesea criticate pentru următoarele dezavantaje:

Redundanţă. În marea majoritate a cazurilor, criticii spun că UML este prea mare și complex, iar acest lucru este adesea nejustificat. Include destul de multe desene și diagrame redundante sau practic inutile, iar de cele mai multe ori astfel de critici sunt îndreptate către cea de-a doua versiune, nu către prima, deoarece revizuirile mai noi conțin 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, nu are rigiditatea care este inerentă limbilor definite cu precizie prin tehnici 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. Descrierile imprecise ale limbajului în sine afectează atât utilizatorii, cât și furnizorii de instrumente, ducând în cele din urmă la incompatibilitatea instrumentelor din cauza modului unic de tratare a diferitelor specificații.
Probleme în procesul de implementare și învățare. 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 de lucru în sine, adică codul este proiectul. Conform acestui punct de vedere, este necesar să se dezvolte un mod mai eficient de a scrie software. UML este apreciat în mod obișnuit în abordările care compilează modele pentru a regenera codul executabil sau sursă. 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 la ceea ce instrumentul de interpretare UML poate ghici 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 o altă ieșire. Ca și în cazul oricărei notații standard, UML poate reprezenta unele sisteme mai eficient și mai concis decât altele. Astfel, dezvoltatorul este mai înclinat către acele soluții care sunt mai confortabile în împletirea tuturor punctelor forte ale UML, precum și ale altor limbaje de programare. Această problemă este mai evidentă dacă limbajul de dezvoltare nu se conformează principiilor de bază ale ortodoxiei orientate pe obiecte, adică nu încearcă să funcționeze în conformitate cu principiile OOP.
Încearcă să fie universal. UML este un limbaj de modelare de uz general care încearcă să fie compatibil cu orice limbaj de procesare disponibil în prezent. În contextul unui proiect dat, pentru ca echipa de proiectare să atingă scopul final, este necesar să se selecteze caracteristicile aplicabile ale limbajului respectiv. În plus, posibilele modalități de a limita domeniul de aplicare al UML într-o anumită zonă sunt printr-un formalism care nu este pe deplin articulat și care este supus criticii.

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