& nbsp & nbsp & nbsp & nbsp Unified Modeling Language (UML) este un limbaj pentru specificarea, vizualizarea, construirea și documentarea sisteme software, precum și modele de afaceri și alte sisteme non-software. UML este o combinație de tehnici de inginerie care au fost utilizate anterior cu succes pentru a modela sisteme mari și complexe.
& nbsp & nbsp & nbsp & nbsp Creatorii UML îl reprezintă ca un limbaj pentru definirea, reprezentarea, proiectarea și documentarea sistemelor software, a sistemelor de afaceri și a altor sisteme de natură variată. UML definește notația și metamodelul. O notație este o colecție de obiecte grafice care sunt utilizate în modele; este sintaxa unui limbaj de modelare.
UML & nbsp & nbsp & nbsp & nbsp oferă instrumente expresive pentru crearea de modele vizuale care:
- înțeles uniform de toți dezvoltatorii implicați în proiect;
- sunt un mijloc de comunicare în cadrul proiectului.
& nbsp & nbsp & nbsp & nbsp Unified Modeling Language (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.
& nbsp & nbsp & nbsp & nbsp UML este open source și extensibil la nucleul de bază. În UML, puteți descrie în mod semnificativ clase, obiecte și componente din diferite domenii, adesea foarte diferite unele de altele.
Diagramele UML
& nbsp & nbsp & nbsp & nbsp 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 de caz de utilizare
- Diagrama de implementare (diagrame de topologie);
- Diagrama de stat;
- Diagrama de interacțiune Diagrama activității
- Diagrama secvenței
- Diagrama de colaborare
- Diagrama de clasă
- Diagrama componentelor
- Diagrame de comportament
- Diagrama activității
- Diagrame de implementare
& nbsp & nbsp & nbsp & nbsp Fiecare dintre aceste diagrame concretizează o vedere diferită a modelului de sistem. În acest caz, diagrama cazurilor de utilizare reprezintă un model conceptual al sistemului, care este punctul de plecare pentru construirea tuturor celorlalte diagrame. O diagramă de clasă este un model logic care reflectă aspectele statice ale designului structural al unui sistem, iar diagramele de comportament, care sunt, de asemenea, varietăți ale unui model logic, reflectă aspectele dinamice ale funcționării acestuia. Diagramele de implementare sunt folosite pentru a reprezenta componentele unui sistem și se referă la modelul său fizic.
& nbsp & nbsp & nbsp & nbsp Din diagramele de mai sus, unele sunt folosite pentru a indica două sau mai multe subspecii. Următoarele diagrame sunt utilizate ca reprezentări independente: cazuri de utilizare, clase, stări, activități, secvență, cooperare, componente și implementări.
& nbsp & nbsp & nbsp & nbsp Există trei tipuri de simboluri 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 trasate în apropierea imaginilor grafice.
& nbsp & nbsp & nbsp & nbsp La afișarea grafică a diagramelor, se recomandă să respectați următoarele reguli:
- fiecare diagramă ar trebui să fie o reprezentare completă a unui fragment al domeniului simulat;
- entităţile modelului reprezentate pe diagramă trebuie să fie de acelaşi nivel conceptual;
- toate informațiile despre entități trebuie să fie clar reprezentate î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 trebuie să conțină numai acele elemente care sunt definite în notație UML.
Entități în UML
& nbsp & nbsp & nbsp & nbsp UML definește patru tipuri de entități: structurale, comportamentale, de grupare și adnotare... Entitățile sunt principalele elemente orientate pe obiect ale limbajului cu care sunt create modelele.
& nbsp & nbsp & nbsp & nbsp Entități structurale sunt substantive în modelele UML. De obicei, ele reprezintă părți statice ale modelului care corespund elementelor conceptuale sau fizice ale sistemului. Exemple de entități structurale sunt clasă, interfață, cooperare, caz de utilizare, componentă, nod, actor.
& nbsp & nbsp & nbsp & nbsp Entități comportamentale sunt componente dinamice ale modelului UML. Acestea sunt verbe care descriu comportamentul unui model î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 de comportament care determină succesiunea stărilor prin care trece un obiect sau o interacțiune ca răspuns la diverse evenimente.
& nbsp & nbsp & nbsp & nbsp Gruparea entităților sunt părțile organizatoare ale modelului UML. Acestea sunt blocurile în care modelul poate fi descompus. Există o singură copie a unei astfel de entități primare - este un pachet.
& nbsp & nbsp & nbsp & nbsp Pachetele sunt un mecanism universal pentru organizarea articolelor în grupuri. Entitățile structurale, comportamentale și alte entități de grupare pot fi plasate în pachet. Spre deosebire de componentele care există de fapt în timpul rulării programului, pachetele sunt pur conceptuale, adică există doar în timpul procesului de dezvoltare.
& nbsp & nbsp & nbsp & nbsp Entități de adnotare sunt părțile 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, adnotarea. O notă este folosită pentru a furniza comentarii sau constrângeri la diagrame, exprimate în text informal sau formal.
Relații în UML
& nbsp & nbsp & nbsp & nbsp Următoarele tipuri de relații sunt definite în UML: dependență, asociere, generalizare și implementare... Aceste relații sunt principalele constructe adezive în UML și sunt, de asemenea, modul în care entitățile sunt utilizate pentru a construi modele.
& nbsp & nbsp & nbsp & nbsp Dependenţă este o relație semantică între două entități, în care o modificare a uneia dintre ele, independentă, poate afecta semantica celeilalte, dependente.
& nbsp & nbsp & nbsp & nbsp Asociere- o relație structurală care descrie un set de conexiuni semantice sau logice între obiecte.
& nbsp & nbsp & nbsp & nbsp Generalizare este o relație în care un obiect element specializat (descendent) poate fi înlocuit cu un obiect element generic (strămoș). În același timp, în conformitate cu principiile programării orientate pe obiecte, copilul moștenește structura și comportamentul părintelui său (părinte).
& nbsp & nbsp & nbsp & nbsp Realizare este o relație semantică între clasificatori în care un clasificator definește o obligație, iar celălalt garantează îndeplinirea acesteia. O relație de implementare apare în două cazuri:
- între interfețe și clasele sau componentele care le implementează;
- între cazurile de utilizare și colaborările care le implementează.
Mecanisme comune UML
& nbsp & nbsp & nbsp & nbsp Pentru o descriere precisă a sistemului în UML, sunt folosite așa-numitele mecanisme generale:
- specificații;
- adaosuri (podoabe);
- diviziuni (diviziuni comune);
- mecanisme de extensibilitate.
& nbsp & nbsp & nbsp & nbsp UML nu este doar un limbaj grafic. Fiecare element grafic al notației sale are specificație conţinând 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, modelul poate conține o altă reprezentare a acestei clase, reflectând 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.
& nbsp & nbsp & nbsp & nbsp Aproape fiecare element UML are o reprezentare grafică unică care oferă o reprezentare vizuală a celor mai importante caracteristici ale sale. Notația de entitate „clasă” conține numele, atributele și operațiile sale. O specificație de clasă 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 redate sub formă de grafică sau text. adaosuri la dreptunghiul standard care reprezintă clasa.
& nbsp & nbsp & nbsp & nbsp Când modelați sisteme orientate pe obiecte, există o anumită Divizia entitati reprezentate.
& nbsp & nbsp & nbsp & nbsp În primul rând, există o împărțire în clase și obiecte. O clasă este o abstracție, iar un obiect este o întruchipare concretă a acelei abstracțiuni. În acest sens, aproape toate constructele limbajului sunt caracterizate de o dualitate clasă/obiect. Deci, există cazuri de utilizare și cazuri de utilizare, componente și instanțe de componente, noduri și instanțe de nod. Î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.
& nbsp & nbsp & nbsp & nbsp În al doilea rând, există o împărțire în interfață și implementarea acesteia. Interfața declară angajamente, iar implementarea reprezintă întruchiparea concretă a acelor angajamente și asigură că semantica declarată este urmărită îndeaproape. Din acest motiv, aproape toate constructele UML sunt caracterizate prin dualitate interfață / implementare. De exemplu, cazurile de utilizare sunt implementate de cooperative, iar operațiunile prin metode.
& nbsp & nbsp & nbsp & nbsp UML este limba deschisă, adică permite extensiilor controlate pentru a reflecta specificul modelelor de domenii.
& nbsp & nbsp & nbsp & nbsp Mecanismele de extensie UML includ:
- stereotipuri (stereotipuri) - extinde vocabularul UML, permițând, pe baza elementelor de limbaj existente, crearea altora noi care să fie axate pe rezolvarea unei probleme specifice;
- tagged value - extinde proprietățile constructelor UML de bază, permițând ca informații suplimentare să fie incluse în specificația elementului;
- constrângeri - extindeți semantica constructelor UML, permițându-vă să creați reguli noi și să înlocuiți regulile existente.
& nbsp & nbsp & nbsp & nbsp Î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
& nbsp & nbsp & nbsp & nbsp Acest tip de diagramă vă permite să creați o listă de operațiuni pe care le efectuează sistemul. Acest tip de diagramă este adesea denumit diagramă funcțională, deoarece o listă de cerințe de sistem este creată pe baza unui set de astfel de diagrame și se stabilește setul de funcții efectuate de sistem.
Figura - 1. Diagrama cazurilor de utilizare
& nbsp & nbsp & nbsp & nbsp Diagramele de cazuri de utilizare descriu funcționalitatea unui sistem sau ceea ce ar trebui să facă sistemul. Dezvoltarea diagramei are următoarele obiective:
- definiți limitele generale și contextul domeniului simulat;
- 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.
& nbsp & nbsp & nbsp & nbsp 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 prin cazuri de utilizare. În acest caz, un 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 ca sursă de influență asupra sistemului modelat, așa cum îl determină dezvoltatorul însuși. Utilizare caz servește pentru a descrie serviciile pe care sistemul le oferă actorului.
& nbsp & nbsp & nbsp & nbsp Scopul unui caz de utilizare este de a defini un aspect sau fragment complet al comportamentului unei entități fără a dezvălui structura sa internă. O astfel de entitate poate fi un sistem sau orice element al unui model care are propriul comportament.
& nbsp & nbsp & nbsp & nbsp Fiecare caz de utilizare corespunde unui serviciu separat pe care entitatea modelată îl oferă la cererea actorului, adică determină modul în care este utilizată acea entitate. Serviciul, care este inițializat la cererea actorului, este o secvență completă, indivizibilă de acțiuni. Aceasta înseamnă că, după ce sistemul termină procesarea cererii, ar trebui să revină la starea initiala pentru a fi pregătit pentru următoarele întrebări
& nbsp & nbsp & nbsp & nbsp Cazurile de utilizare pot fi utilizate atât pentru specificarea cerințelor externe pentru sistemul proiectat, cât și pentru specificarea comportamentului funcțional deja sistemul existent... Setul de cazuri de utilizare în ansamblu ar trebui să definească toate părțile 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 vizualizate ca un pachet separat.
& nbsp & nbsp & nbsp & nbsp Exemplele de cazuri de utilizare includ: verificarea stării contului curent al unui client, plasarea unei comenzi pentru achiziționarea unui articol, obținerea de informații suplimentare despre bonitatea unui client, afișarea unui formular grafic pe un ecran de monitor, si alte actiuni.
Diagrama de clasă
& nbsp & nbsp & nbsp & nbsp Esențial pentru programarea orientată pe obiecte este dezvoltarea unui model logic al unui sistem sub forma unei diagrame de clasă. O diagramă de clasă (diagrama de clasă) este utilizată pentru a reprezenta structura statică a unui model 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, cum ar fi obiectele și subsistemele, precum și să descrie structura lor internă și tipurile de relații.
Figura - 2. Diagrama de clasă
& nbsp & nbsp & nbsp & nbsp Pictogramele de diagramă vă permit să afișați o ierarhie complexă de sisteme, relații de clasă (Class) ș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ă într-o varietate de notații. ca un nor. Astfel, o clasă este doar un șablon, conform căruia un anumit obiect va fi creat în viitor.
& nbsp & nbsp & nbsp & nbsp O diagramă de clasă este un grafic, ale cărui vârfuri sunt elemente de tip „clasificator”, conectate tipuri diferite 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.
& nbsp & nbsp & nbsp & nbsp Clasăîn limbajul UML, este folosit pentru a desemna un set de obiecte care au aceeași structură, comportament și relații cu obiectele din alte clase. Clasa este reprezentată grafic 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)
& nbsp & nbsp & nbsp & nbsp Fiecare diagramă de stări din UML 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ăspunsul său la influențele externe.
& nbsp & nbsp & nbsp & nbsp Diagramele de stat sunt cel mai frecvent utilizate pentru a descrie comportamentul obiectelor individuale, dar pot fi utilizate ș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
& nbsp & nbsp & nbsp & nbsp Diagrama de stat 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 stare pot fi imbricate unele în altele pentru o prezentare mai detaliată a elementelor individuale ale modelului.
& nbsp & nbsp & nbsp & nbsp În metamodelul UML mașinărie este un pachet care definește un set de concepte necesare pentru a reprezenta comportamentul unei entități modelate sub forma unui spațiu discret cu un număr finit de stări și tranziții.
& nbsp & nbsp & nbsp & nbsp Durata prezenței sistemului în oricare dintre stările posibile depășește semnificativ timpul necesar pentru 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.
& nbsp & nbsp & nbsp & nbsp Comportamentul mașinii este modelat ca deplasare secvențială de-a lungul graficului de la vârf la vârf, ținând cont de orientarea arcurilor care le conectează.
& nbsp & nbsp & nbsp & nbsp Trebuie îndeplinite următoarele cerințe preliminare pentru mașină:
- starea în care poate ajunge un obiect este determinată doar de starea sa actuală și nu depinde de istorie;
- în fiecare moment de timp automatul poate fi în doar una dintre stările sale. În același timp, automatul poate rămâne într-o stare separată pentru orice perioadă de timp, dacă nu au loc evenimente;
- timpul în care mașina se află într-o anumită stare, precum și timpul necesar pentru a ajunge la o anumită stare, nu sunt specificate în niciun fel;
- numărul de stări ale automatului trebuie să fie finit și toate 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 luate în considerare;
- graficul automatului nu trebuie să conțină stări și tranziții izolate. Pentru fiecare stare, cu excepția celei inițiale, trebuie definită o stare anterioară, iar fiecare tranziție trebuie să conecteze două stări ale automatului;
- automatul nu trebuie să conțină tranziții conflictuale, când obiectul poate merge simultan în două sau mai multe stări ulterioare (cu excepția cazului sub-automatelor paralele). În UML, conflictele pot fi evitate prin introducerea unor condiții de gardă.
state 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 UML are o serie de caracteristici specifice.
& nbsp & nbsp & nbsp & nbsp În UML, starea este o metaclasă abstractă folosită pentru a modela o singură situație în care sunt îndeplinite anumite condiții. Starea poate fi specificată ca un set de valori specifice pentru atributele unei clase sau ale unui obiect. Modificările la valorile atributelor individuale vor reflecta modificări ale stării clasei sau obiectului modelat.
Diagrama activității
& nbsp & nbsp & nbsp & nbsp La modelarea comportamentului unui sistem proiectat sau analizat, devine necesar nu numai reprezentarea procesului de modificare a stărilor acestuia, ci și detalierea caracteristicilor implementării algoritmice și logice a operațiunilor efectuate de către sistemul.
& nbsp & nbsp & nbsp & nbsp De fapt tipul dat diagramele pot fi, de asemenea, folosite pentru a reflecta stările unui obiect modelat, cu toate acestea, scopul principal al unei diagrame de activitate este de a reflecta procesele de afaceri ale unui obiect. Acest tip de diagramă vă permite să afișați nu numai succesiunea proceselor, ci și ramificarea și chiar sincronizarea proceselor.
& nbsp & nbsp & nbsp & nbsp Acest tip de diagrame vă permite să proiectați algoritmi pentru comportamentul obiectelor de orice complexitate, inclusiv pot fi folosite pentru a întocmi diagrame bloc.
& nbsp & nbsp & nbsp & nbsp Diagramele de activitate sunt folosite pentru a modela procesul de efectuare a operațiunilor în limbajul UML. Notația grafică pe care o folosesc este foarte asemănătoare cu notația diagramă de stat prin faptul că include și stări și tranziții. Fiecare stare de pe diagrama de activitate corespunde executării unei operații elementare, iar trecerea la următoarea stare se realizează numai după finalizarea acestei operații.
& nbsp & nbsp & nbsp & nbsp Astfel, diagramele de activitate pot fi considerate un caz special de diagrame de stare. Acestea vă permit să implementați în limbajul UML caracteristici de control procedural și sincron, datorită finalizării activităților și acțiunilor interne. Direcția principală de utilizare a diagramelor de activitate este vizualizarea particularităților implementării operațiilor de clasă, atunci când este necesar să se prezinte algoritmi pentru executarea acestora.
& nbsp & nbsp & nbsp & nbsp În contextul UML activitate este o colecție de calcule individuale efectuate de mașină, care conduc la un rezultat sau acțiune (acțiune). Diagrama de activitate afișează logica și succesiunea tranzițiilor de la o activitate la alta, iar atenția analistului este concentrată asupra rezultatelor. Rezultatul activității poate duce la o schimbare a stării sistemului sau la revenirea unei anumite valori.
& nbsp & nbsp & nbsp & nbsp 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 care părăsește starea. 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ă. O utilizare comună a stării de acțiune este de a simula un singur pas în execuția unui algoritm (procedură) sau a unui flux de control.
Diagrama secvenței
& nbsp & nbsp & nbsp & nbsp 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ă în modelarea proceselor sincrone care descriu interacțiunea obiectelor. UML folosește diagrame de secvență pentru a modela interacțiunea obiectelor în timp.
& nbsp & nbsp & nbsp & nbsp Diagrama secvenței 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.
& nbsp & nbsp & nbsp & nbsp În UML, o diagramă de secvență are două dimensiuni. Prima de la stânga la dreapta sub formă de linii verticale, fiecare dintre acestea ilustrând linia vieții unui obiect separat care participă la interacțiune. În partea stângă a diagramei este prezentat obiectul care inițiază interacțiunea. În dreapta, este înfățișat un alt obiect, care interacționează direct cu primul. Astfel, toate obiectele din diagrama de secvență formează un fel de ordine, determinată de ordinea sau gradul de activitate al obiectelor în interacțiunea între ele.
& nbsp & nbsp & nbsp & nbsp Grafic, fiecare obiect este reprezentat ca un dreptunghi și este situat în partea de sus a liniei sale de viață. Numele obiectului și numele clasei sunt scrise în interiorul dreptunghiului, separate prin două puncte. În acest caz, întreaga înregistrare este subliniată, ceea ce este o caracteristică a obiectului.
& nbsp & nbsp & nbsp & nbsp A doua dimensiune a diagramei secvențe este axa verticală a timpului de sus în jos. Partea cea mai de sus a diagramei corespunde momentului inițial în timp. Interacțiunile obiectelor sunt implementate prin mesaje care sunt trimise de la un obiect la altul. Mesajele sunt afișate ca săgeți orizontale cu numele mesajului, iar ordinea lor este determinată de momentul apariției. Adică, mesajele situate în diagrama de secvență de mai sus sunt declanșate mai devreme decât cele situate mai jos. Scara de pe axa timpului nu este indicată deoarece diagrama de secvență modelează doar ordonarea temporală a interacțiunilor anterioare-ulterioare.
Diagrama de colaborare
& nbsp & nbsp & nbsp & nbsp caracteristica principală Diagrama 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
& nbsp & nbsp & nbsp & nbsp Acest tip de diagramă vă permite să descrieți interacțiunea obiectelor, făcând abstracție din secvența de transmitere a mesajelor. Toate mesajele primite și transmise ale unui anumit obiect și tipurile acestor mesaje sunt reflectate în acest tip de diagrame într-o formă compactă.
& nbsp & nbsp & nbsp & nbsp În primul rând, diagrama de cooperare sub formă de dreptunghiuri prezintă obiectele care participă la interacțiune, conținâ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 descrise legături dinamice - fluxuri de mesaje. Ele sunt, de asemenea, reprezentate ca linii de legătură între obiecte, deasupra cărora există o săgeată care indică direcția, numele mesajului și numărul de secvență în secvența generală de inițializare a mesajului.
& nbsp & nbsp & nbsp & nbsp Spre deosebire de diagrama secvență, o diagramă de colaborare descrie doar relațiile dintre obiecte 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 determinată folosind numerele de secvență. Prin urmare, dacă trebuie să specificați în mod explicit relațiile dintre obiecte în timp real, cel mai bine este să faceți acest lucru într-o diagramă de secvență.
& nbsp & nbsp & nbsp & nbsp Concept colaborare 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 modelat. 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.
& nbsp & nbsp & nbsp & nbsp Cooperarea poate fi prezentată pe două niveluri:
- nivelul de specificație - arată rolurile clasificatorilor și rolul asociațiilor în interacțiunea avută în vedere;
- nivel de exemplu - indică instanțele și relațiile care formează roluri separate în cooperare.
& nbsp & nbsp & nbsp & nbsp Diagrama de cooperare la nivel BOM 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.
& nbsp & nbsp & nbsp & nbsp O diagramă de cooperare la nivel de exemplu este reprezentată de o colecție de obiecte (instanțe de clasă) și relații (instanțe de asociere). În acest caz, linkurile sunt completate cu săgeți pentru mesaje. Pe acest nivel sunt prezentate 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.
& nbsp & nbsp & nbsp & nbsp De aici rezultă o consecință importantă. Unul și același set de obiecte poate participa în diferite cooperative. În funcție de cooperarea luată în considerare, atât proprietățile obiectelor individuale, cât și conexiunile dintre ele se pot schimba. Acesta este ceea ce distinge o diagramă de colaborare de o diagramă de clasă, care trebuie să indice toate proprietățile și asocierile dintre elementele diagramei.
Diagrama componentelor
& nbsp & nbsp & nbsp & nbsp Acest tip de diagramă este destinat distribuirii claselor și obiectelor pe componentă în proiectarea fizică a sistemului. Acest tip de diagramă este adesea denumit diagrame unitare.
Figura - 4. Diagrama componentelor
& nbsp & nbsp & nbsp & nbsp Un design complet al unui sistem software este un set de modele ale nivelurilor logice și fizice, care trebuie să fie în concordanță între ele. UML utilizează diagrame de implementare pentru a reprezenta fizic modele de sisteme, care includ diagrama componentelorși diagrama de implementare.
& nbsp & nbsp & nbsp & nbsp Diagrama componentelor, spre deosebire de diagramele considerate anterior, descrie caracteristicile reprezentării fizice a sistemului. Vă permite să definiți arhitectura sistemului în curs de dezvoltare prin stabilirea de 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 acestora.
& nbsp & nbsp & nbsp & nbsp Diagrama componentelor este dezvoltată în următoarele scopuri:
- vizualizări structura generala cod sursa sistem software;
- specificațiile versiunii executabile a sistemului software;
- asigurarea reutilizarii fragmentelor individuale ale codului programului;
- reprezentări ale schemelor de baze de date conceptuale și fizice.
& nbsp & nbsp & nbsp & nbsp Analiștii și arhitecții de sistem, precum și programatorii sunt implicați în dezvoltarea diagramelor de componente. O diagramă de componente oferă o tranziție consistentă de la o vedere logică la o implementare specifică a unui proiect 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. O diagramă de componente reflectă dependențele generale dintre componente, considerându-le pe acestea din urmă ca clasificatori.
& nbsp & nbsp & nbsp & nbsp Pentru a reprezenta entitățile fizice în limbajul UML, se folosește un termen special - componentă... Componenta implementează un anumit set de interfețe și servește pentru desemnarea generală a elementelor reprezentării fizice a modelului. Pentru a reprezenta grafic componenta, utilizați caracter special- un dreptunghi cu două dreptunghiuri mai mici introduse în stânga. În interiorul dreptunghiului mare este scris numele componentei și, dacă este necesar, câteva Informații suplimentare... Reprezentarea acestui simbol poate varia ușor în funcție de natura informațiilor asociate cu componenta.
Diagrama de implementare
& nbsp & nbsp & nbsp & nbsp Acest tip de diagrame este conceput pentru a analiza hardware-ul sistemului, adică „hardware”, și nu programe. Într-o traducere directă din engleză, Deployment înseamnă „implementare”, dar termenul „topologie” reflectă mai exact esența acestui tip de diagrame.
Figura - 5. Diagrama de implementare
& nbsp & nbsp & nbsp & nbsp Reprezentarea fizică a unui sistem software nu poate fi completă dacă nu există informații despre ce platformă și pe care facilitati de calcul a fost implementat. Dacă este în curs de dezvoltare un program care rulează local pe computerul utilizatorului și nu utilizează dispozitive și resurse periferice, atunci nu este nevoie să dezvoltați diagrame suplimentare. La dezvoltarea aplicațiilor corporative, prezența unor astfel de diagrame poate fi extrem de utilă pentru rezolvarea problemelor de plasare rațională a componentelor în vederea utilizare eficientă resurse de rețea de calcul și comunicații distribuite, securitate și altele.
& nbsp & nbsp & nbsp & nbsp Diagramele de implementare sunt concepute pentru a reprezenta configurația generală și topologia unui sistem software distribuit în UML.
& nbsp & nbsp & nbsp & nbsp Diagrama de implementare este concepută pentru a vizualiza elementele și componentele programului care există doar în stadiul execuției acestuia (runtime). În acest caz, sunt prezentate doar componentele-instanțe ale programului, care sunt fișiere executabile sau biblioteci dinamice. Componentele care nu sunt utilizate în timpul execuției nu sunt afișate în diagrama de implementare. Deci, componentele cu coduri sursă ale programelor pot fi prezente doar în diagrama componentelor. Ele nu sunt prezentate în diagrama de implementare.
& nbsp & nbsp & nbsp & nbsp O diagramă de implementare conține reprezentări grafice ale procesoarelor, dispozitivelor, proceselor și relațiilor dintre ele. Spre deosebire de diagramele de vizualizare logică, o diagramă de implementare este uniformă pentru sistemul în ansamblu, deoarece trebuie să reflecte pe deplin specificul implementării sale. Dezvoltarea unei diagrame de implementare este de obicei ultimul pas în specificarea modelului de sistem software.
& nbsp & nbsp & nbsp & nbsp Când se dezvoltă o diagramă de implementare, se urmăresc următoarele obiective:
- determina distribuția componentelor sistemului după nodurile sale fizice;
- arata conexiunile fizice dintre toate nodurile implementarii sistemului la etapa de executie a acestuia;
- identificați blocajele din sistem și reconfigurați topologia acestuia pentru a obține performanța necesară.
& nbsp & nbsp & nbsp & nbsp Diagramele de implementare sunt dezvoltate în comun de analiști de sisteme, ingineri de rețea și ingineri de sisteme.
Caracteristici ale interfeței desktop Rational Rose
& nbsp & nbsp & nbsp & nbsp Instrumentul Rational Rose CASE implementează standarde general acceptate pentru interfața de lucru a programului, similar mediilor de programare vizuală bine-cunoscute. După instalarea Rational Rose pe computerul utilizatorului, ceea ce practic nu creează dificultăți nici măcar începătorilor, lansarea acestui program în mediul MS Windows 95/98 are ca rezultat o interfață funcțională pe ecran (Fig. 6).
Figura - 6. Vedere generală a interfeței de lucru a programului Rational Rose
& nbsp & nbsp & nbsp & nbsp Interfața de lucru Rational Rose constă din diferite elemente, dintre care principalele sunt:
- Meniul principal al programului
- Fereastra diagramă
- Fereastra de documentare
- Fereastra browserului
- Fereastra 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 individuale de meniu, 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 familiare (deschiderea unui proiect, ieșirea și 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
Panou standard instrumente se află sub meniul principal al programului și are următoarea formă (Fig. 8). Unele dintre instrumente nu sunt disponibile (noul proiect nu are elemente). Bara de instrumente standard oferă acces rapid la comenzile de meniu pe care dezvoltatorii le execută cel mai frecvent.
Figura - 8. Aspectul barei de instrumente standard
Utilizatorul poate personaliza aspectul acestui panou la propria discreție. Pentru a face acest lucru, selectați elementul de meniu Instrumente -> Opțiuni și deschideți fila Bare de instrumente. În acest fel, puteți afișa sau ascunde diferitele butoane de instrumente și puteți modifica dimensiunea acestora.
Fereastra browserului
În mod implicit, fereastra 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 simplifică navigarea și vă permite să găsiți orice element de model în proiectul dumneavoastră. În acest caz, orice element pe care dezvoltatorul îl adaugă modelului este afișat imediat în fereastra browserului. În consecință, după ce am selectat 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 elementele între diferite vizualizări ale modelului. Dacă se dorește, fereastra browserului poate fi poziționată în alt loc al interfeței de lucru sau ascunsă complet folosind elementul de meniu Vizualizare. De asemenea, puteți redimensiona browserul trăgând marginea cadrului său exterior.
Figura - 9. Aspectul browserului
Bară de instrumente dedicată
O bară de instrumente specială este situată între fereastra browserului și fereastra diagramă în mijlocul interfeței de lucru. În mod implicit, este oferită o bară de instrumente pentru construirea unei diagrame de clasă a modelului (Fig. 10).
Figura - 10. Apariția unei bare de instrumente dedicate diagramei de clasă
Puteți schimba locația barei de instrumente speciale 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 sfaturile instrumente care apar după ce cursorul mouse-ului este oprit peste butonul corespunzător.
Fereastra diagramă
Fereastra diagramă este zona principală de lucru a interfeței sale, în care sunt vizualizate diferite vederi 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 al modelului (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 extinsă 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 implementare este activă, deși sunt disponibile alte diagrame. Comutarea între diagrame se poate face selectând vizualizarea dorită pe bara de instrumente standard sau prin elementul de meniu Fereastră. La activarea unui tip separat de diagramă, aspectul unei bare de instrumente speciale se schimbă, care este ajustată pentru un anumit tip de diagramă.
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 elementului de meniu View -> Documentation, după care va apărea sub browser (Fig. 12).
Fereastra de documentare, după cum sugerează și numele, este pentru documentarea elementelor vederii modelului. Puteți scrie o varietate de informații în el ș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.
În fereastra de documentație, sunt activate informațiile care se referă la un element selectat separat 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 acestuia 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 și pentru alte ferestre ale interfeței de lucru, puteți modifica dimensiunea și poziția ferestrei de documentație.
Figura - 12. Aspectul ferestrei de documentare
Fereastra jurnal
Fereastra Jurnal 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 mesajele de eroare care apar la generarea codului programului.
Fereastra de jurnal este întotdeauna prezentă pe interfața de lucru în zona ferestrei diagramei (Fig. 13). Cu toate acestea, poate fi închis prin alte ferestre de diagramă sau minimizat. Puteți activa fereastra de jurnal prin meniul Fereastră-> Jurnal. În acest caz, este afișat deasupra altor ferestre în panoul din dreapta al interfeței de lucru. Această fereastră nu poate fi eliminată complet, poate fi doar minimizată.
Figura - 13. Aspectul ferestrei de jurnal
Concluzie
& nbsp & nbsp & nbsp & nbsp În timp, UML va deveni „Esperanto” în care matematicienii, analiștii de sisteme, fizicienii, programatorii, managerii, economiștii și specialiștii altor profesii pot comunica, prezentându-și cunoștințele profesionale într-o formă unificată. La urma urmei, în esență, fiecare dintre specialiști operează cu concepte model în domeniul său de cunoaștere. Și tocmai acest aspect de model poate fi specificat prin intermediul limbajului UML.
& nbsp & nbsp & nbsp & nbsp În acest sens, importanța limbajului UML crește semnificativ, deoarece capătă din ce în ce mai mult caracteristicile unui limbaj de reprezentare a cunoștințelor. În același timp, prezența în UML a mijloacelor picturale de reprezentare a structurii și comportamentului unui model 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 cunoştinţe. Toate aceste caracteristici ale UML ne permit să concluzionam că are cele mai serioase perspective în viitorul apropiat.
Acest articol examinează noua eră a dezvoltării software, impactul acesteia asupra noilor cerințe pentru UML și cele mai bune practici pentru îndeplinirea acestora.
& nbsp 7. „Modelarea datelor în Rational Rose” Sergey Trofimov Descrie modelarea reprezentării datelor fizice folosind Rational Rose
& nbsp 8. Limbajul UML. Înțelegerea generală a limbajului UML: structuri, elemente grafice și diagrame ale limbajului.
& nbsp 9. UML practic. Acest document este o traducere a UML practic. O introducere practică pentru dezvoltatori. O introducere practică pentru dezvoltatori
& nbsp 10. „Limbajul standard al modelării orientate pe obiecte UML” Vendrov Alexander Mikhailovici. Istoria UML
& nbsp 11. UML este un limbaj de modelare unificat. Acest material conține informațiile inițiale despre metodele de descriere a sistemelor software și notațiile utilizate în UML.
& nbsp 12. Limbajul UML. Manualul utilizatorului. De Grady Booch, James Rambeau, Ivar Jacobson
& nbsp 13. „Diagramele UML în Rational Rose” Sergey Trofimov
& nbsp 14. "Analiză și design. Modelare vizuală (UML) Rational Rose" Konstantin Domolego
& nbsp 15. Biblioteca lui Ghenadi Vernikov. Descrieri complete standarde de proiectare și modelare.
& nbsp 16. „Un exemplu de descriere a unui domeniu care utilizează UML în dezvoltarea sistemelor software” Ye.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)
& nbsp & nbsp & nbsp & nbsp
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 a sistemelor software bazate pe abordarea OO, pentru a organiza relația dintre conceptele conceptuale și software, pentru a reflecta problemele de scalare a sistemelor complexe. Modelele în UML sunt utilizate în toate etapele ciclului de viață al sistemului software, de la analiza afacerii până la întreținerea sistemului. Diferite organizații pot aplica UML după cum consideră de cuviință, în funcție de zonele lor problematice și de tehnologiile utilizate.
O scurtă istorie a UML
La mijlocul anilor '90, câteva zeci de metode de modelare OO au fost propuse de diverși autori, fiecare dintre acestea folosind propria notație grafică. În același timp, oricare dintre aceste metode avea atuurile lor, dar nu permitea construirea unui model PS suficient de complet, arătându-l „din toate părțile”, adică toate proiecțiile necesare (Vezi articolul 1). În plus, lipsa unui standard de modelare OO a îngreunat pentru dezvoltatori alegerea celei mai potrivite metode, ceea ce a împiedicat utilizarea pe scară largă a abordării OO pentru dezvoltarea software.
La solicitarea Object Management Group (OMG) - organizația 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 Buch, D. Rambo și A. Jacobson, care au unit eforturile, au creat UML 1.1, care a fost aprobat de OMG în 1997 ca standard.
UML este un limbaj
Orice limbă constă dintr-un vocabular și reguli de combinare a cuvintelor pentru a obține construcții semnificative. Deci, în special, sunt aranjate limbaje de programare, cum ar fi UML. Caracteristica sa distinctivă este că dicționarul de limbă este format din elemente grafice. Fiecare simbol grafic are o semantică specifică, astfel încât un model creat de un dezvoltator poate fi înțeles fără ambiguitate de către altul, precum și un instrument software care interpretează UML-ul. Din aceasta, în special, rezultă că un model PS prezentat în UML poate fi tradus automat într-un limbaj de programare OO (precum Java, C++, VisualBasic), adică dacă există un instrument bun de modelare vizuală care acceptă UML , construind modelul , vom primi o pregatire a codului programului corespunzator acestui model.
Trebuie subliniat faptul că UML este un limbaj, nu o metodă. Explică din ce elemente să creăm modele și cum să le citești, dar nu spune nimic despre ce modele ar trebui dezvoltate și în ce cazuri. Pentru a crea o metodă bazată pe UML, este necesar să o completați cu o descriere a procesului de dezvoltare a software-ului. Un exemplu de astfel de proces este Procesul Rațional Unificat, care va fi discutat în articolele următoare.
Vocabularul UML
Modelul este reprezentat sub formă de entități și relații dintre ele, care sunt prezentate în diagrame.
Entități Sunt abstracțiile 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 adnotare (comentarii). Fiecare tip de entitate are propria sa reprezentare grafică. Entitățile vor fi discutate în detaliu atunci când explorați diagramele.
Relaţie arată diverse relații între entități. UML definește următoarele tipuri de relații:
- Dependenta arată o astfel de legătură între două entități, atunci când schimbarea uneia dintre ele - independentă - poate afecta semantica celeilalte - dependente. Dependența este reprezentată de o săgeată întreruptă care indică de la entitatea dependentă la entitatea independentă.
- Asociere Este o relație structurală care arată că obiectele dintr-o entitate sunt legate de obiectele din alta. O asociere este afișată grafic ca o linie care conectează entitățile care sunt legate. Asociațiile sunt folosite pentru a naviga între obiecte. De exemplu, asocierea dintre clasele „Comandă” și „Produs” poate fi utilizată pentru a găsi toate bunurile specificate într-o anumită comandă - pe de o parte, sau pentru a găsi toate comenzile în care există un anumit produs - pe de altă parte. . Este clar că programele corespunzătoare trebuie să implementeze un mecanism pentru o astfel de navigare. Dacă este necesară o singură direcție pentru a naviga, aceasta este indicată printr-o săgeată la sfârșitul asocierii. Un caz special al unei asociații este agregarea - o relație de forma „întreg” - „parte”. Grafic, este evidențiat cu un diamant la sfârșit lângă entitate-întreg.
- Generalizare Este o relație între o entitate-mamă și o entitate descendentă. În esență, această relație reflectă proprietatea de moștenire 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 membri de structură și noi metode. UML permite moștenirea multiplă atunci când o entitate este asociată cu 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 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 pentru a crea ierarhii. Nu există diagrame de pachete separate în UML, dar ele pot apărea în alte diagrame. Pachetul este afișat ca dreptunghi cu o filă.
Ce oferă UML.
- o descriere ierarhică a unui sistem complex prin alocarea de pachete;
- 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;
- evidențierea claselor de date și construirea unui model conceptual de date sub formă de diagrame de clasă;
- evidenţierea claselor descriind interfața cu utilizatorulși crearea unei scheme de navigare pentru ecrane;
- o descriere a proceselor de interacțiune a obiectelor la î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;
- o descriere a arhitecturii fizice a sistemului.
Și ultimul ...
În ciuda tuturor atractivității UML, ar fi dificil să-l folosești în modelarea software 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 coduri de program necompletate în diferite limbaje de programare OO și să creați scheme de baze de date. Cele mai multe dintre ele includ posibilitatea reinginerării 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 asigura consistența modelului și a codurilor și la proiectarea sistemelor care moștenesc funcționalitatea predecesorului. sisteme.
Ce este UML?
Dacă te uiți la imaginile din motoare de căutare, atunci devine clar că UML- este ceva despre diagrame, săgeți și pătrate. Ceea ce este important este că UML este tradus ca Limbajul de modelare unificat... Cuvântul Unificat este important aici. Adică pozele noastre vor fi înțelese nu numai de noi, ci și de alții care cunosc UML. Se pare că aceasta este o limbă atât de internațională pentru desenarea diagramelor.
Cum spune Wikipedia
UML este un limbaj de descriere grafică pentru modelarea obiectelor în dezvoltarea de software, modelarea proceselor de afaceri, Ingineria Sistemelorși afișarea structurilor organizatorice.Cel mai interesant lucru, despre care nu toată lumea gândește sau ghicește, UML are specificații. Și există chiar și o specificație UML2. Mai multe detalii despre specificație pot fi găsite pe site-ul Object Management Group. De fapt, acest grup este implicat în dezvoltarea specificațiilor UML. De asemenea, este interesant că UML nu se limitează la descrierea structurii claselor. Există multe tipuri de diagrame UML. O scurtă descriere a tipurilor de diagrame UML poate fi văzută în aceeași Wikipedia: UML - diagrame sau în videoclipul lui Timur Batyrshinov Prezentare generală a diagramelor UML... UML este, de asemenea, utilizat pe scară largă în descrierea diferitelor procese, de exemplu aici: SSO folosind JWT. Revenind la utilizarea diagramelor de clasă UML, merită remarcată cartea Head First: Design Patterns, în care modelele sunt ilustrate cu aceleași diagrame UML. Se pare că UML-ul este într-adevăr folosit. Și se dovedește că cunoașterea și înțelegerea aplicației sale este o abilitate destul de utilă.
Aplicație
Să vedem cum poți lucra cu acest UML din IDE. Ca IDE, să luăm IntelliJ Idea... Dacă utilizați IntelliJ Idea Ultimate, apoi pluginul va fi instalat „din cutie” Suport UML". Vă permite să generați automat diagrame de clasă frumoase. De exemplu, prin Ctrl + N sau elementul de meniu" Navigați "->" Clasă "mergeți la clasă ArrayList... Acum prin meniul contextual după numele clasei, selectați „Diagramă” -> „Afișați pop-up diagramă”. Ca rezultat, vom obține o diagramă frumoasă:
Dar dacă vrei să te desenezi și chiar dacă nu există o versiune Ultimate a Ideei? Dacă folosim IntelliJ Idea Community Edition, atunci nu avem altă opțiune. Pentru a face acest lucru, trebuie să înțelegeți cum funcționează o astfel de diagramă UML. În primul rând, trebuie să instalăm Graphviz. Este un set de utilități de vizualizare grafică. Este folosit de pluginul pe care îl vom folosi. După instalare, trebuie să adăugați directorul cos din directorul instalat Graphviz la variabila de mediu CALE... După aceea, în IntelliJ Idea, selectați Fișier -> Setări din meniu. În fereastra „Setări”, selectați categoria „Plugin-uri”, faceți clic pe butonul „Răsfoiți depozitele” și instalați pluginul de integrare PlantUML. Ce este atât de bine în asta PlantUML? Folosește un limbaj grafic numit „ punct„iar asta îi permite să fie mai versatil, pentru că limba dată nu se folosește numai PlantUML. În plus, tot ceea ce facem mai jos îl putem face nu numai în IDE, ci și în serviciu online planttext.com. După instalarea pluginului PlantUML, vom putea crea diagrame UML prin „Fișier” -> „Nou”. Să creăm o diagramă de tipul „UML class”. În acest timp, un șablon cu un exemplu este generat automat. Să-i ștergem conținutul și să creăm al nostru, înarmat cu un articol din Habr: Relații de clasă - de la UML la cod. Și pentru a înțelege cum să descriem acest lucru în text, să luăm manualul PlantUML: plantuml class-diagram. În ea, la început, există o placă cu cum se descrie conexiunile:
În ceea ce privește legăturile în sine, mai putem arunca o privire aici: „Relații între clase în UML. Exemple”. Pe baza acestor materiale, să începem să creăm diagrama noastră UML. Să adăugăm următorul conținut care descrie cele două clase: @startuml class ArrayList () class LinkedList () @enduml Pentru a vedea rezultatul în Idea, selectați "View" -> " Instrument Windows"->" PlantUML ". Obținem doar două pătrate reprezentând clasele. După cum știm, ambele clase implementează interfața Listă. Această atitudine clasele se numesc - implementare (realizare). O săgeată cu o linie întreruptă este folosită pentru a descrie o astfel de conexiune. Să o reprezentăm: Listă Listă interfață< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о pachet privat matrice de elemente: ~ Object elementData Acum vrem să arătăm că ArrayList conține câteva obiecte. În acest caz, tipul de link va fi - agregare(agregare). Agregatul în acest caz este ArrayList, deoarece contine si alte obiecte. Alegem agregarea deoarece obiectele din listă pot trăi fără listă: nu sunt părți integrante ale acesteia. Viața lor nu este legată de durata de viață a listei. Agregat se traduce din latină ca „asamblat”, adică ceva alcătuit din ceva. De exemplu, în viață, există o unitate de pompare, care constă dintr-o pompă și un motor. Unitatea în sine poate fi dezasamblată, lăsând ceva din ea părți componente... De exemplu, pentru a vinde sau a pune în altă unitate. Deci este pe listă. Și acest lucru este exprimat sub forma unui diamant gol la unitate și a unei linii continue. Să o descriem astfel: clasa Object () ArrayList o- Object Acum dorim să arătăm că, spre deosebire de ArrayList, clasa LinkedList conține Node - containere care se referă la date stocate. În acest caz, nodurile fac parte din LinkedList în sine și nu pot trăi separat. Node nu este conținut stocat direct, ci conține doar un link către acesta. De exemplu, când adăugăm o linie la LinkedList, adăugăm un nou Nod care conține o legătură către acea linie, precum și o legătură către Nodul anterior și următorul. Acest tip de comunicare se numește compoziţie(Compoziţie). Pentru a afișa compozitul (cel format din piese), este desenat un robot pictat, o linie continuă duce la acesta. Acum să scriem asta sub forma unei afișari textuale a link-ului: class Node () LinkedList * - Node Și acum trebuie să învățăm cum să afișam un alt tip important de link - dependenta(relație de dependență). Este folosit atunci când o clasă folosește alta, iar clasa nu conține clasa utilizată și nu moștenește de la ea. De exemplu, LinkedList și ArrayList ambele știu cum să creeze un ListIterator. Reprezentăm aceasta ca săgeți cu o linie punctată: clasa ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Puteți detalia atât cât este necesar. Toate denumirile sunt enumerate aici: "PlantUML - Diagrama de clasă". În plus, nu există nimic supranatural în desenarea unei astfel de diagrame și, atunci când lucrați la sarcinile dvs., o puteți desena rapid cu mâna. Acest lucru vă va ajuta să vă dezvoltați abilitățile de gândire privind arhitectura aplicației și să identificați defectele din structura clasei devreme, mai degrabă decât după ce ați petrecut ziua implementând modelul greșit. Cred că acesta este un motiv bun pentru a încerca?)
Automatizare
Există căi diferite generare automată diagrame PlantUML. De exemplu, în Idee există un plugin SketchIT, dar nu le desenează corect. Să presupunem că implementarea interfețelor este desenată incorect (afișată ca moștenire). Există, de asemenea, exemple pe Internet despre cum să integrați acest lucru în ciclul de viață al proiectului dumneavoastră. Să zicem pentru Maven există un exemplu folosind uml-java-docklet. Pentru a arăta cum este aceasta, să folosim Arhetipul Maven pentru creație rapidă Proiectul Maven. Rulați comanda: mvn archetype: generate Când vi se cere să selectați un filtru ( Alegeți un număr sau aplicați filtrul) părăsiți implicit prin simpla apăsare a Enter. Va fi mereu" maven-arhetip-pornire rapidă". Selectăm cea mai recentă versiune. Apoi răspundem la întrebări și finalizam crearea proiectului:
Deoarece Maven nu este în centrul acestui articol, puteți găsi răspunsuri la întrebările dvs. Maven la Centrul de utilizatori Maven. În proiectul generat, deschideți fișierul de descriere a proiectului pentru editare, pom.xml... Copiați conținutul din descrierea de instalare a uml-java-docklet în el. Artefactul folosit în descriere nu a putut fi găsit în depozitul Maven Central. Dar a funcționat pentru mine cu asta: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Adică trebuie doar să înlocuiți în acea descriere groupId cu " info.leadinglight" pe " com.chfourie"și pune versiunea" 1.0.0 ". După aceea, putem executa în directorul în care se află fișierul pom.xml aceste comenzi: mvn clean install și mvn javadoc: javadoc. Acum, dacă deschidem documentația generată (explorer target\site\apidocs\index.html), vom vedea diagrama UML. Apropo, implementarea este deja afișată corect aici)
Concluzie
După cum puteți vedea, UML vă permite să vizualizați structura aplicației dvs. În plus, UML nu se limitează doar la asta. Folosind UML, puteți descrie diferite procese din cadrul companiei dumneavoastră sau puteți descrie un proces de afaceri în cadrul căruia funcționează o funcție pe care o scrieți. Cât de util este UML-ul pentru dvs. personal depinde de dvs., dar găsirea timpului și cunoașterea mai multor detalii vă va fi util în orice caz. #Viacheslav Versiunea rusă a acestei postări: diagrama UML Java pe CodeGymUML (Unified Modeling Language) este un limbaj de descriere grafică pentru modelarea obiectelor în dezvoltarea de software. UML este un limbaj cu bază largă, un standard deschis care utilizează 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 primul rând sisteme software. UML nu este un limbaj de programare, dar generarea de cod este posibilă în mijloacele 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 cu% 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% 20 Microsoft% 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-% 20 Modelare,% 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% 20 Secvență% 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% 20Utilizare% 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% 20Vizual% 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% 20Vizualizare% 20și% 20Modelare% 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
IBM Rational Rose
Posibilitati:
- Diagrama de caz de utilizare
- Diagrama de implementare (diagrame de topologie);
- Diagrama de stat;
- Diagrama activității
- Diagrama de interacțiune
- Diagrama secvenței
- Diagrama de colaborare
- Diagrama de clasă
- Diagrama componentelor
Capturi de ecran:
Programe open source
StarUML
Posibilitati:
- Suport UML 2.0
- MDA (Arhitectură condusă de model)
- Arhitectură plug-in (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, de exemplu, C / C ++, Java, Visual Basic, Delphi, JScript, VBScript, C #, VB.NET. Mai jos sunt afișate mai multe capturi de ecran.
Diagrama de clasa:
Diagrama cazului de utilizare:
ArgoUML
Diagrame acceptate:
- Clasă
- Stat
- Utilizare caz
- Activitate
- Colaborare
- Implementare
- Secvenţă
Posibilitati:
- 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:
10.4. DIAGRAME UML
10.4.1. Tipuri de diagrame vizuale UML
UML vă permite să creați mai multe tipuri de diagrame vizuale:
Folosiți diagrame de caz
Diagrame de succesiune;
diagrame cooperative;
Diagrame de clasă
Diagrame de stare;
Diagrame componente;
Diagrame de plasare.
Diagramele ilustrează diferite aspecte ale sistemului. De exemplu, o diagramă cooperativă arată modul în care obiectele trebuie să interacționeze pentru a implementa o anumită funcționalitate a sistemului. Fiecare diagramă are propriul său scop.
10.4.2. Folosiți diagrame de caz
Diagramele de cazuri de utilizare descriu interacțiunile dintre cazurile de utilizare reprezentând funcțiile sistemului și actorii, reprezentând oameni sau sisteme, care primesc sau transmit informații în acest sistem... Un exemplu de diagramă de caz de utilizare pentru un ATM este prezentat în Fig. 10.1.
Orez. 10.1. Diagrama de caz de utilizare
Diagrama ilustrează interacțiunile dintre cazurile de utilizare și actori. Acesta reflectă cerințele de sistem din punctul de vedere al utilizatorului. Astfel, cazurile de utilizare sunt funcții îndeplinite de sistem, iar actorii sunt părți interesate în raport cu sistemul care se construiește. Diagramele arată care actori declanșează cazuri de utilizare. Ele arată și când actorul primește informații din cazul de utilizare. În esență, o diagramă de caz de utilizare poate ilustra cerințele de sistem. În exemplul nostru, clientul băncii inițiază diverse cazuri de utilizare: „Retrage bani din cont”, „Transferă bani”, „Adaugă bani în cont”, „Afișează sold”, „Modifică numărul de identificare”, „Efectuează plata”. Funcționarul băncii poate iniția cazul de utilizare a modificării numărului de identificare. Din cazul de utilizare Efectuare plăți, există o săgeată către Sistemul de creditare. Sistemele externe pot fi, de asemenea, actori, în acest caz sistemul de Credit este prezentat exact ca actor - este extern sistemului ATM. O săgeată care indică de la caz de utilizare către actor indică faptul că cazul de utilizare oferă anumite informații actorului. În acest caz, cazul de utilizare „Efectuați o plată” oferă Sistemului de credit informații despre o plată cu cardul de credit.
Destul de multe informații despre sistem pot fi obținute din diagramele de cazuri de utilizare. Acest tip de diagramă descrie funcționalitatea generală a sistemului. Utilizatorii, managerii de proiect, analiștii, dezvoltatorii, specialiștii QA și oricine altcineva care este interesat de sistem în ansamblu pot studia diagramele de caz de utilizare pentru a înțelege ce ar trebui să facă sistemul.
10.4.3. Diagrame de secventa
Diagramele de secvență descriu fluxul de evenimente care au loc într-un caz de utilizare. De exemplu, cazul de utilizare „Retragerea de bani” prevede mai multe secvențe posibile: retragerea de bani, încercarea de a retrage bani în absența unei sume suficiente în cont, încercarea de a retrage bani folosind un număr de identificare incorect și altele. . În Fig. 10.2.
Fig 10.2. Diagrama secvenței pentru retragerea de 20 USD de către clientul Joe din contul său
Partea de sus a diagramei prezintă toți actorii și obiectele necesare sistemului pentru a îndeplini cazul de utilizare Retragere de bani. Săgețile corespund mesajelor transmise între actor și obiect, sau între obiecte pentru a îndeplini funcțiile necesare. De asemenea, trebuie remarcat faptul că diagrama de secvență arată obiectele, nu clasele. Clasele reprezintă tipuri de obiecte. Obiectele sunt specifice; în loc de clasă Client diagrama de secvență reprezintă un anumit client Joe.
Cazul de utilizare începe atunci când clientul își introduce cardul în cititor - acest obiect este afișat în dreptunghiul din partea de sus a diagramei. Citește numărul cardului, deschide obiectul Cont Joe și inițializează ecranul ATM. Ecranul îi cere lui Joe numărul de înregistrare. Clientul introduce numărul 1234. Ecranul verifică numărul de pe obiectul Contul lui Joe și descoperă că este corect. Ecranul îi prezintă apoi lui Joe un meniu de selecție, iar Joe selectează „Retragere bani”. Ecranul întreabă cât dorește să retragă, iar Joe indică 20 de dolari. Ecranul elimină bani din cont. Procedând astfel, inițiază o serie de procese efectuate de obiectul Contul lui Joe. Totodată, se verifică dacă în acest cont există cel puțin 20 USD și se scade suma necesară din cont. Casa de marcat este apoi instruită să „emite un cec și 20 USD în numerar”. În cele din urmă, același obiect Joe's Account îi cere cititorului de carduri să returneze cardul.
Deci, această diagramă de secvență ilustrează fluxul cazului de utilizare Retragere folosind un exemplu specific de retragere de 20 USD de către Client Joe. Privind această diagramă, utilizatorii se familiarizează cu specificul muncii lor. Analiștii văd secvența (fluxul) acțiunilor, dezvoltatorii văd obiectele care trebuie create și operațiunile acestora. Profesioniștii în controlul calității vor înțelege detaliile procesului și pot proiecta teste pentru a le verifica. Astfel, diagramele de secvențe sunt utile tuturor celor implicați în proiect.
10.4.4. Diagrame cooperative
Diagramele cooperative afișează aceleași informații ca și diagramele secvențe. Cu toate acestea, o fac într-un mod diferit și în scopuri diferite. Prezentat în fig. 10.2 o diagramă de secvență este prezentată în fig. 10.3 ca diagramă cooperativă.
Ca și înainte, obiectele sunt descrise ca dreptunghiuri, iar personajele ca figuri. În timp ce o diagramă de secvență arată interacțiunile dintre actori și obiecte în timp, nu există nicio relație cu timpul într-o diagramă cooperativă. Astfel, se poate observa că cititorul de carduri instruiește „contul Joe” să se deschidă, iar „contul Joe” determină cititorul de carduri să returneze cardul proprietarului. Obiectele care interacționează direct sunt conectate prin linii. Dacă, de exemplu, un cititor de carduri comunică direct cu un ecran ATM, trageți o linie între ele. Absența unei linii înseamnă că nu există o comunicare directă între obiecte.
Orez. 10.3. Diagrama cooperativă care descrie procesul de retragere a banilor dintr-un cont
Deci, o diagramă cooperativă afișează aceleași informații ca o diagramă de secvență, dar este necesară pentru alte scopuri. Profesioniștii în controlul calității și arhitecții de sistem vor putea înțelege distribuția proceselor între locații. Să presupunem că un fel de diagramă cooperativă seamănă cu o stea, în care mai multe obiecte sunt asociate cu un obiect central. Arhitectul sistemului poate concluziona că sistemul este prea dependent de instalația centrală și trebuie reproiectat pentru a distribui procesele mai uniform. Într-o diagramă de secvență, acest tip de interacțiune ar fi greu de văzut.
10.4.5. Diagrame de clasă
Diagramele de clasă reflectă interacțiunile dintre clasele dintr-un sistem. De exemplu, „contul lui Joe” este un obiect. Tipul unui astfel de obiect poate fi considerat un cont în general, adică „Contul” este o clasă. Clasele conțin date și comportament (acțiuni) care afectează datele respective. De exemplu, clasa Cont conține numărul de identificare al clientului și acțiunile care îl verifică. Într-o diagramă de clasă, o clasă este generată pentru fiecare tip de obiect din diagrame de secvență sau diagrame cooperative. Diagrama de clasă pentru cazul de utilizare Retragere de bani este prezentată în Figura 4-2. 10.4.
Diagrama arată relațiile dintre clasele care implementează cazul de utilizare Retragere de bani. Există patru clase implicate în acest proces: Cititor de carduri(cititor de carduri), Cont, ATM (ecran ATM) și Distribuitor de numerar (casa de marcat). Fiecare clasă din diagrama de clasă este reprezentată printr-un dreptunghi împărțit în trei părți. Prima parte specifică numele clasei, a doua - ea atribute. Un atribut este o informație care caracterizează o clasă. De exemplu, clasa Cont are trei atribute: Numărul contului, PIN și Sold. Ultima parte conține operațiile clasei care o reflectă comportament(acțiuni efectuate de clasă). Liniile de legătură dintre clase arată interacțiunea dintre clase.
Orez. 10.4. Diagrama de clasă
Dezvoltatorii folosesc diagrame de clase pentru a crea efectiv clase. Instrumente precum Rose generează o bază de cod pentru clasele pe care programatorii le completează cu detalii în limba preferată. Cu aceste diagrame, analiștii pot arăta detaliile sistemului, iar arhitecții pot înțelege designul. Dacă, de exemplu, o clasă poartă prea multă sarcină funcțională, aceasta va fi vizibilă în diagrama de clase, iar arhitectul o poate redistribui între alte clase. De asemenea, puteți utiliza diagrama pentru a identifica cazurile în care nu sunt definite relații între clasele care comunică. Diagramele de clasă trebuie create pentru a arăta clasele care interacționează în fiecare caz de utilizare. De asemenea, puteți construi diagrame mai generale care să acopere toate sistemele sau subsistemele.
10.4.6. Diagrame de stări
Diagramele de stare sunt concepute pentru a modela diferitele stări în care se poate afla un obiect. În timp ce diagramele de clasă arată o imagine statică a claselor și a relațiilor lor, diagramele de stare sunt folosite pentru a descrie dinamica comportamentului unui sistem.
Diagramele de stare descriu comportamentul unui obiect. De exemplu, un cont bancar poate avea mai multe stări diferite. Poate fi deschis, închis sau creditul pentru acesta poate fi depășit. Comportamentul contului se modifică în funcție de starea în care se află. Diagrama de stare arată exact aceste informații. În fig. 10.5 este un exemplu de diagramă de stare pentru un cont bancar.
Orez. 10.5. Diagrama de stare pentru clasa de cont
Această diagramă arată stările posibile ale contului, precum și procesul de tranziție a contului de la o stare la alta. De exemplu, dacă un client solicită închiderea unui cont deschis, acesta din urmă intră în starea „Închis”. Cerința clientului este numită eveniment, evenimentele sunt cele care provoacă trecerea de la o stare la alta.
Când un client retrage bani dintr-un cont deschis, contul poate intra în starea „Exces de credit”. Acest lucru se întâmplă numai dacă soldul contului este mai mic decât zero, așa cum este reflectat de condiția [sold negativ] din graficul nostru. Inclus între paranteze drepte condiție determină când poate sau nu să aibă loc o tranziție de la o stare la alta.
Există două stări speciale în diagramă - iniţialăși finala. Starea inițială este evidențiată cu un punct negru: corespunde stării obiectului la momentul creării acestuia. Starea finală este indicată printr-un punct negru într-un cerc alb: corespunde stării obiectului chiar înainte de a fi distrus. Într-o diagramă de stări poate exista una și o singură stare inițială. În același timp, pot exista atâtea stări finale câte aveți nevoie sau poate să nu existe deloc.
Când un obiect se află într-o anumită stare, anumite procese pot fi executate. În exemplul nostru, atunci când împrumutul este depășit, un mesaj corespunzător este trimis clientului. Procesele care apar atunci când un obiect se află într-o anumită stare sunt numite actiuni.
Diagramele de stare nu trebuie create pentru fiecare clasă, ele se aplică doar în foarte cazuri dificile... Dacă un obiect de clasă poate exista în mai multe stări și se poate comporta diferit în fiecare dintre ele, probabil că va avea nevoie de o astfel de diagramă. Cu toate acestea, în multe proiecte nu sunt folosite deloc. Dacă, totuși, s-au construit diagrame de stare, dezvoltatorii le pot folosi atunci când creează clase.
Diagramele de stare sunt necesare în principal în scopuri de documentare.
10.4.7. Diagrame componente
Diagramele componente arată cum arată modelul la nivelul fizic. Acesta descrie componentele software ale sistemului dvs. și conexiunile dintre ele. În același timp, se disting două tipuri de componente: componente executabile și biblioteci de coduri.
În fig. 10.6 ilustrează una dintre diagramele componente pentru un sistem ATM. Această diagramă prezintă componentele unui client de sistem ATM. În acest caz, echipa de dezvoltare a decis să construiască sistemul folosind limbajul C++. Fiecare clasă are propriul său fișier antet și fișier cu extensia. CPP, astfel încât fiecare clasă să fie mapată cu propriile componente din diagramă. Se numește componenta întunecată evidențiată specificația pachetuluiși corespunde fișierului body al clasei ATM în C ++ (fișier cu extensia .CPP). O componentă neselectată se mai numește și specificație de pachet, dar corespunde fișierului antet al clasei C ++ (fișier cu extensia .H). componenta ATM. exe este o specificație pentru o sarcină și reprezintă fluxul de procesare a informațiilor. În acest caz, un fir de procesare este un program executabil.
Componentele sunt conectate printr-o linie întreruptă care arată dependențele dintre ele. Un sistem poate avea mai multe diagrame de componente, în funcție de numărul de subsisteme sau executabile. Fiecare subsistem este un pachet de componente.
Diagramele componentelor sunt utilizate de către acei participanți la proiect care sunt responsabili de compilarea sistemului. Diagrama componentelor vă oferă o idee despre ordinea în care trebuie compilate componentele, precum și despre componentele executabile care vor fi generate de sistem. Diagrama arată corespondența claselor cu componentele implementate. Deci, este necesar acolo unde începe generarea de cod.
Orez. 10.6. Diagrama componentelor
10.4.8. Diagrame de plasare
Diagramele de amplasare arată locația fizică a diferitelor componente ale sistemului dintr-o rețea. În exemplul nostru, sistemul ATM constă dintr-un număr mare de subsisteme care rulează pe dispozitive sau noduri fizice separate. Diagrama de dispunere a sistemului ATM este prezentată în Fig. 10.7.
Din această diagramă, puteți afla despre locația fizică a sistemului. Programele client ATM vor rula în mai multe locații pe site-uri diferite. Clienții vor comunica cu serverul ATM regional prin rețelele închise. O sa mearga software Server ATM. La rândul său, prin retea locala serverul regional va interacționa cu serverul bazei de date bancare care rulează Oracle. În cele din urmă, o imprimantă este conectată la serverul ATM regional.
Deci, această diagramă arată locația fizică a sistemului. De exemplu, sistemul nostru ATM urmează o arhitectură cu trei niveluri, primul nivel găzduind baza de date, al doilea cu serverul regional și al treilea cu clientul.
10.7. Diagrama de amplasare
Diagrama de aspect este utilizată de managerul de proiect, utilizatori, arhitectul de sistem și personalul de operațiuni pentru a afla aspectul fizic al unui sistem și locația subsistemelor sale individuale. Managerul de proiect va explica utilizatorilor cum va arăta produsul finit. Personalul de exploatare va putea planifica lucrările de instalare a sistemului.
Din carte Microsoft Office autorul Leontiev Vitali PetroviciDiagrame Numerele din tabel nu dau întotdeauna o impresie completă, chiar dacă sunt sortate în modul cel mai convenabil pentru dvs. Utilizarea disponibilă în Microsoft Excelșabloane de diagrame, puteți obține o imagine vizuală a datelor din tabel și, în plus,
Din cartea Computer 100. Noțiuni introductive cu Windows Vista autor Zozulya YuriDiagrame Diagramele sunt folosite pentru a reprezenta date tabelare în grafic, ceea ce face posibilă îmbunătățirea semnificativă a clarității informațiilor, pentru a afișa raportul diferiților parametri sau dinamica modificării acestora. Pentru a insera diagrame în Word, utilizați instrumentele
Din cartea Munca eficientă de birou autorul Ptaşinski Vladimir SergheeviciDiagrame Cea mai vizuală caracteristică a Excel este prezentarea rezultatelor calculelor sau a datelor acumulate sub formă de grafice (diagrame): uneori, cele mai impresionante cifre nu sunt capabile să convingă cum se poate face folosind nici măcar grafice simple. Excel are
Dintr-un registru de lucru Excel. Curs multimedia autorul Medinov OlegCapitolul 8 Diagrame Deseori programul Excel sunt folosite pentru a crea documente reprezentând diverse rapoarte statistice și analitice. Acestea pot fi rapoarte de vânzări, tabele de măsurători ale temperaturii aerului, date din sondaje de opinie etc. Cifrele nu sunt întotdeauna
Din cartea Tutorial popular Word 2007 autorul Krainsky IConstruirea unei diagrame Pentru primul exemplu, va trebui să creați tabelul prezentat în Fig. 8.1. Orez. 8.1. Tabel de măsurare a temperaturii Vom construi un grafic simplu al temperaturii pe baza datelor din acest tabel. 1. Selectați intervalul completat din tabel. 2. Mergi la
Din cartea Ghid de auto-studiu pentru lucrul la computer autorul Kolisnichenko Denis Nikolaevici6.6. Diagrame Pe lângă fișierele grafice, puteți insera diagrame în documentele Word. Cu ajutorul diagramelor, puteți vizualiza date numerice, de exemplu, urmăriți modul în care se schimbă datele, vedeți dezvoltarea unui proiect în dinamică. Diagramele devin similare
Din cartea Analiză și proiectare orientată pe obiecte cu exemple de aplicații C ++ autorul Butch Grady14.9. Diagrame Poate că este timpul să transformăm numerele uscate în grafice, făcând tabelul nostru mai frumos și mai informativ? Pentru aceasta se folosesc diagrame. Spuneți ce vă place, dar o diagramă este percepută mai bine decât un tabel. Pentru a construi o diagramă, trebuie să selectați valorile după care
Din cartea Tehnologii de programare autor Kamaev VA5.2. Diagramele de clasă Esențiale: Clasele și relația dintre ele O diagramă de clasă arată clasele și relațiile lor, reprezentând astfel aspectul logic al unui proiect. O diagramă de clasă separată oferă o vedere specifică a structurii clasei. În faza de analiză, noi
Din cartea Modelarea proceselor de afaceri cu BPwin 4.0 autorul Maklakov Serghei Vladimirovici5.4. Diagramele de obiecte esențiale: obiectele și relațiile lor O diagramă de obiecte arată obiectele existente și relațiile lor în proiectarea sistemului logic. Cu alte cuvinte, o diagramă de obiect este un instantaneu al fluxului de evenimente într-o anumită configurație.
Din cartea OrCAD PSpice. Analiza circuitului electric de Keown J.5.7. Diagrame de proces. Esențial: procesoare, dispozitive și conexiuni Diagramele de proces sunt utilizate pentru a arăta distribuția proceselor între procesoare în proiectarea fizică a unui sistem. Diagrama de proces separată care arată o vedere a structurii procesului
Din VBA Book for Dummies autorul Cummings Steve10.4. DIAGRAME UML 10.4.1. Tipuri de diagrame vizuale UMLUML vă permite să creați mai multe tipuri de diagrame vizuale: diagrame de caz de utilizare; diagrame de secvențe; organigrame cooperative; diagrame de clasă; diagrame de stare; grafice
Din cartea Tutorial for Macintosh autoarea Skrylina Sophia1.2.6. Diagrama wireframe 1.2.26 prezintă un exemplu tipic de diagramă de descompunere cu casete de delimitare, numită diagramă wireframe. Orez. 1.2.26. Exemplu de diagramă de descompunere cu wireframe Un wireframe conține un antet (partea de sus a cadrului) și un subsol (de jos).
Din cartea autoruluiDiagrame de sincronizare Pentru a obține diagramele de timp ale tensiunilor de intrare și de ieșire, trebuie să modificați ușor fișierul de intrare. Ca și în exemplul anterior, se va utiliza o tensiune de intrare sinusoidală: Vi 1 0 sin (0 0,5V 5kHz) Împreună cu analiza tranzitorie
Din cartea autoruluiDiagrame și grafice Numai un specialist poate discerne semnificația din spatele serii nesfârșite de numere, dar toată lumea poate înțelege (sau cel puțin să declare că înțelege) o histogramă sau o diagramă circulară. VBA nu are instrumente de diagrame încorporate, dar așa
Din cartea autorului5.1.14. Diagrame Diagramele sunt o reprezentare grafică a datelor numerice din tabel. Pages oferă mai multe tipuri de diagrame: coloană, coloană stivuită, bară, bară stivuită, linie, zonă, zonă stivuită
Din cartea autorului5.2.8. Diagrame O diagramă este o reprezentare grafică a datelor dintr-un interval selectat. Pentru a construi o diagramă, urmați algoritmul de mai jos: 1. Creați un tabel de valori calculate. 2. Selectați intervalul dorit (poate consta din dreptunghiulare neadiacente
