Diagrame de structură Uml. Diagrame UML

UML este acum notația standard de modelare vizuală. sisteme software, adoptat de consorțiul Object Managing Group (OMG) în toamna anului 1997, care este susținut de multe produse CASE orientate pe obiecte.

Standardul UML oferă următorul set de diagrame pentru modelare:

· diagramă de caz de utilizare – pentru modelarea proceselor de afaceri ale unei organizații sau întreprinderi și determinarea cerințelor pentru sistemul informațional care se creează;

· diagramă de clase – pentru modelarea structurii statice a claselor de sistem și a conexiunilor dintre acestea;

· diagrame de comportament ale sistemului;

· diagrame de interacțiune;

· diagrame de secvențe – pentru modelarea procesului de mesagerie între obiecte într-un singur caz de utilizare;

· diagramă de colaborare – pentru modelarea procesului de mesagerie între obiecte în cadrul unui singur caz de utilizare;

· diagramă statechart – pentru modelarea comportamentului obiectelor de sistem în timpul trecerii de la o stare la alta;

· diagramă de activitate – pentru modelarea comportamentului sistemului în cadrul diferitelor cazuri de utilizare, sau activități de modelare;

diagrame de implementare:

· diagrame de componente – pentru modelarea ierarhiei componentelor (subsistemelor) unui sistem informatic;

· diagrama de implementare – pentru modelarea arhitecturii fizice a sistemului informatic proiectat.

În fig. 1.1 prezintă un model integrat al unui sistem informațional, inclusiv principalele diagrame care ar trebui dezvoltate în acest proiect de curs.

Orez. 1. Model integrat al unui sistem informatic în notație UML

4.2. Diagrama de caz de utilizare

Un caz de utilizare este o secvență de acțiuni efectuate de sistem ca răspuns la un eveniment inițiat de un obiect extern (actor). Un caz de utilizare descrie o interacțiune tipică între un utilizator și un sistem. În cel mai simplu caz, cazul de utilizare este determinat în procesul de discutare cu utilizatorul a funcțiilor pe care acesta ar dori să le implementeze în acest sistem informațional. În UML, un caz de utilizare este descris după cum urmează:

Fig.2. Caz de utilizare

Un actor este rolul pe care îl joacă un utilizator în raport cu sistemul. Actorii reprezintă roluri, nu anumite persoane sau titluri de post. Deși sunt descrise ca figuri umane stilizate în diagramele de cazuri de utilizare, un actor poate fi și un exterior sistem informatic, care are nevoie de unele informații din acest sistem. Actorii ar trebui să fie afișați pe diagramă doar dacă au nevoie de anumite cazuri de utilizare. În UML, actorii sunt reprezentați ca forme:

Fig.3. Personaj (actor)

Actorii sunt împărțiți în trei tipuri principale:

· utilizatori;

· sisteme;

· alte sisteme care interacționează cu acesta;

Timpul devine actor dacă de el depinde lansarea oricăror evenimente din sistem.

4.2.1. Relațiile dintre cazurile de utilizare și actori

În UML, diagramele de caz de utilizare acceptă mai multe tipuri de relații între elementele diagramei:

· comunicare

includere (includere),

· extindere (extindere),

· generalizare.

legătura de comunicare este relația dintre un caz de utilizare și un actor. În UML, relațiile de comunicare sunt afișate folosind o asociere unidirecțională (linie continuă).

Fig.4. Exemplu de legătură de comunicare

Activați conexiunea utilizat în situațiile în care există o parte din comportamentul sistemului care se repetă în mai multe cazuri de utilizare. Aceste conexiuni sunt de obicei folosite pentru a modela o funcție reutilizabilă.

Comunicare de extindere folosit pentru a descrie schimbări în comportamentul normal al unui sistem. Permite utilizarea unui singur caz de utilizare atunci când este necesar funcţionalitate alt caz de utilizare.

Fig.5. Exemplu de relație de includere și extindere

Conexiunea de generalizare arată că mai mulți actori sau clase au proprietăți comune.

Fig.6. Exemplu de link de generalizare

4.3.

Diagrame de interacțiune descrie comportamentul grupurilor de obiecte care interacționează. De obicei, o diagramă de interacțiune acoperă comportamentul obiectelor într-un singur caz de utilizare. O astfel de diagramă afișează un număr de obiecte și mesajele pe care le schimbă între ele.

Mesaj este mijlocul prin care un obiect expeditor solicită unui obiect destinatar să efectueze una dintre operațiunile sale.

Mesaj de informare este un mesaj care oferă obiectului destinatar unele informații pentru a-și actualiza starea.

Solicitare mesaj (interogativ) este un mesaj care solicită eliberarea unor informații despre obiectul destinatar.

Mesaj imperativ este un mesaj care solicită obiectului destinatar să efectueze o acțiune.

Există două tipuri de diagrame de interacțiune: diagrame de secvență și diagrame de colaborare.

4.3.1. Diagrame de secvențe

Diagrama secvenței reflectă fluxul de evenimente care au loc într-un singur caz de utilizare.

Toți actorii (actori, clase sau obiecte) implicați într-un anumit scenariu (caz de utilizare) sunt afișați în partea de sus a diagramei. Săgețile corespund mesajelor transmise între un actor și un obiect sau între obiecte pentru a îndeplini funcțiile necesare.

Într-o diagramă de secvență, un obiect este reprezentat ca un dreptunghi cu o linie verticală punctată trasă din el. Această linie se numește linia de salvare a obiectului . Reprezintă un fragment din ciclul de viață al unui obiect în procesul de interacțiune.

Fiecare mesaj este reprezentat ca o săgeată între liniile de viață a două obiecte. Mesajele apar în ordinea în care apar pe pagină de sus în jos. Fiecare mesaj este etichetat cu cel puțin un nume de mesaj. Dacă doriți, puteți adăuga și argumente și câteva informații de control. Puteți arăta autodelegarea - un mesaj pe care un obiect îl trimite la sine, cu săgeata de mesaj îndreptată către aceeași linie de viață.

Orez. 7. Exemplu de diagramă de succesiune

4.3.2. Diagrama de colaborare

Diagrame de cooperare afișează fluxul de evenimente într-un scenariu specific (caz de utilizare). Mesajele sunt ordonate în funcție de timp, deși diagramele de colaborare se concentrează mai mult pe conexiunile dintre obiecte. O diagramă de colaborare prezintă toate informațiile care sunt prezente într-o diagramă de secvență, dar o diagramă de colaborare descrie fluxul evenimentelor în mod diferit. Face mai ușor de înțeles conexiunile care există între obiecte.

Într-o diagramă de colaborare, la fel ca într-o diagramă de secvență, săgețile reprezintă mesaje schimbate într-un anumit caz de utilizare. Secvența lor de timp este indicată prin numerotarea mesajelor.

Orez. 8. Exemplu de diagramă de cooperare

4.4. Diagrama de clasă

4.4.1. Informații generale

Diagrama de clasă definește tipurile de clase ale sistemului și diferitele tipuri de conexiuni statice care există între ele. Diagramele de clasă descriu, de asemenea, atributele claselor, operațiile claselor și constrângerile care sunt impuse relațiilor dintre clase.

O diagramă de clasă în limbajul UML este un grafic ale cărui noduri sunt elemente ale structurii statice a proiectului (clase, interfețe), iar arcele sunt relațiile dintre noduri (asocieri, moștenire, dependențe).

Diagrama de clasă prezintă următoarele elemente:

· Pachet - un set de elemente de model legate logic între ele;

· Clasa (clasa) - descrierea proprietatilor comune ale unui grup de obiecte similare;

· Interfață - o clasă abstractă care specifică un set de operații pe care un obiect dintr-o clasă arbitrară asociată cu o interfață dată le oferă altor obiecte.

4.4.2. Clasă

Clasă este un grup de entități (obiecte) care au proprietăți similare, și anume date și comportament. Un reprezentant individual al unei clase este numit obiect al clasei sau pur și simplu obiect.

Comportamentul unui obiect în UML se referă la orice reguli pentru interacțiunea unui obiect cu lumea exterioarăși cu datele obiectului însuși.

În diagrame, o clasă este reprezentată ca un dreptunghi cu un chenar solid, împărțit linii orizontale in 3 sectiuni:

Secțiunea de sus (secțiunea de nume) conține numele clasei și alte proprietăți generale (în special, stereotipul).

Secțiunea din mijloc conține o listă de atribute

În partea de jos este o listă de operații de clasă care reflectă comportamentul acesteia (acțiuni efectuate de clasă).

Este posibil ca oricare dintre secțiunile de atribute și operații să nu fie afișate (sau ambele simultan). Pentru o secțiune lipsă, nu trebuie să trasați o linie de despărțire sau să indicați în niciun fel prezența sau absența elementelor în ea.

Secțiuni suplimentare, cum ar fi excepții, pot fi introduse la discreția implementării specifice.

Orez. 9. Exemplu de diagramă de clasă

4.4.2.1.Stereotipuri de clasă

Stereotipurile de clasă sunt un mecanism de împărțire a claselor în categorii.

UML definește trei stereotipuri principale de clasă:

Graniță (graniță);

Entitate (entitate);

Controla.

4.4.2.2.Clasele limită

Clasele limită sunt acele clase care sunt situate la limita sistemului și a întregului mediu. Acest formulare de ecran, rapoarte, interfețe cu hardware (cum ar fi imprimante sau scanere) și interfețe cu alte sisteme.

Pentru a găsi clase de limită, trebuie să examinați diagramele de caz de utilizare. Fiecare interacțiune dintre un actor și un caz de utilizare trebuie să fie asociată cu cel puțin o clasă limită. Această clasă permite unui actor să interacționeze cu sistemul.

4.4.2.3.Clasele de entitati

Clasele de entități conțin informații stocate. Ele au cel mai mare înțeles pentru utilizator și, prin urmare, numele lor folosesc adesea termeni din domeniul subiectului. De obicei, un tabel este creat în baza de date pentru fiecare clasă de entitate.

4.4.2.4.Clasele de control

Clasele de control sunt responsabile pentru coordonarea acțiunilor altor clase. De obicei, fiecare caz de utilizare are o clasă de control care controlează secvența de evenimente pentru acel caz de utilizare. Clasa de control este responsabilă de coordonare, dar nu are ea însăși nicio funcționalitate, deoarece celelalte clase nu o trimit cantitate mare mesaje. În schimb, el trimite el însuși multe mesaje. O clasă de manager pur și simplu deleagă responsabilitatea altor clase, motiv pentru care este adesea numită clasă de manager.

Pot exista și alte clase de control în sistem care sunt comune pentru mai multe cazuri de utilizare. De exemplu, poate exista o clasă SecurityManager (manager de securitate) responsabilă de monitorizarea evenimentelor legate de securitate. Clasa TransactionManager este responsabilă pentru coordonarea mesajelor legate de tranzacțiile cu bazele de date. Pot exista alți manageri care să se ocupe de alte elemente ale funcționării sistemului, cum ar fi partajarea resurselor, procesarea distribuită a datelor sau gestionarea erorilor.

Pe lângă stereotipurile menționate mai sus, vă puteți crea propriile dvs.

4.4.2.5.Atribute

Un atribut este un element de informație asociat unei clase. Atributele stochează date de clasă încapsulate.

Deoarece atributele sunt conținute într-o clasă, ele sunt ascunse de alte clase. Din acest motiv, poate fi necesar să specificați care clase au dreptul de a citi și modifica atributele. Această proprietate se numește vizibilitate a atributului.

Atributul poate avea patru valori posibile pentru acest parametru:

Public (general, deschis). Această valoare de vizibilitate presupune că atributul va fi vizibil pentru toate celelalte clase. Orice clasă poate vizualiza sau modifica valoarea unui atribut. Conform notației UML, un atribut comun este precedat de un semn „+”.

Privat (închis, secret). Atributul corespunzător nu este vizibil pentru nicio altă clasă. Un atribut privat este notat printr-un semn „–” conform notației UML.

Protejat (protejat). Acest atribut este disponibil numai pentru clasa în sine și pentru descendenții acesteia. Notația UML pentru un atribut protejat este semnul „#”.

Pachetul sau implementarea Presupune că atributul este partajat, dar numai în domeniul de aplicare al pachetului său. Acest tip de vizibilitate nu este indicat de nicio pictogramă specială.

Cu ajutorul închiderii sau securității, este posibil să se evite o situație în care valoarea unui atribut este schimbată de toate clasele sistemului. În schimb, logica pentru modificarea atributului va fi conținută în aceeași clasă ca și atributul în sine. Setările de vizibilitate pe care le setați vor afecta codul generat.

4.4.2.6.Operațiuni

Operațiile implementează comportamentul asociat unei clase. O operație are trei părți: un nume, parametri și un tip de returnare.

Parametrii sunt argumentele primite de operație ca intrare. Tipul de returnare se referă la rezultatul operației.

O diagramă de clasă poate afișa atât numele operațiunilor, cât și numele operațiunilor, împreună cu parametrii și tipul de returnare. Pentru a reduce sarcina pe diagramă, este util să afișați numai numele operațiunilor pe unele dintre ele și semnătura lor completă pe altele.

În UML, operațiunile au următoarea notație:

Nume operație (argument: tip de date argument, tip de date argument2:tip de date argument2,...): tip de returnare

Sunt patru de luat în considerare diverse tipuri operatii:

Operațiuni de implementare;

Operațiuni de management;

Operațiuni de acces;

Operatii auxiliare.

Operațiuni de implementare

Operațiunile de implementare implementează anumite funcții de afaceri. Astfel de operații pot fi găsite examinând diagramele de interacțiune. Acest tip de diagramă se concentrează pe funcțiile de afaceri și fiecare mesaj din diagramă poate fi mapat la o activitate de implementare.

Fiecare operațiune de implementare trebuie să fie ușor de urmărit la cerințele corespunzătoare. Acest lucru se realizează în diferite etape ale simulării. Activitatea este derivată din mesajul din diagrama de interacțiune, mesajele provin dintr-o descriere detaliată a fluxului de evenimente care este creată pe baza cazului de utilizare, iar aceasta din urmă este creată pe baza cerințelor. Capacitatea de a urmări întregul lanț vă permite să vă asigurați că fiecare cerință este implementată în cod și fiecare bucată de cod implementează o anumită cerință.

Operațiuni de control

Operațiunile managerului controlează crearea și distrugerea obiectelor. Constructorii și destructorii de clasă se încadrează în această categorie.

Operațiuni de acces

Atributele sunt de obicei private sau protejate. Cu toate acestea, alte clase trebuie uneori să-și vadă sau să-și schimbe valorile. Există operațiuni de acces în acest scop. Această abordare face posibilă încapsularea în siguranță a atributelor într-o clasă, protejându-le de alte clase, dar permițând totuși acces controlat la ele. Este standard să se creeze operații Get și Set pentru fiecare atribut de clasă.

Operații auxiliare

Operațiile helper sunt acele operațiuni ale unei clase care sunt necesare pentru ca aceasta să-și îndeplinească responsabilitățile, dar despre care alte clase nu ar trebui să știe nimic. Acestea sunt operațiuni de clasă privată și protejată.

Pentru a identifica tranzacțiile, urmați acești pași:

1. Învață diagramele secvențe și diagramele cooperative. Majoritatea mesajelor din aceste diagrame sunt operațiuni de implementare. Mesajele reflectorizante vor fi operații auxiliare.

2. Luați în considerare operațiunile de control. Poate fi necesar să adăugați constructori și destructori.

3. Luați în considerare operațiunile de acces. Pentru fiecare atribut de clasă cu care vor trebui să lucreze alte clase, trebuie să creați operațiuni Get și Set.

4.4.2.7.Conexiuni

O relație reprezintă o relație semantică între clase. Oferă unei clase capacitatea de a învăța despre atributele, operațiile și relațiile unei alte clase. Cu alte cuvinte, pentru ca o clasă să trimită un mesaj către alta într-o diagramă de secvență sau diagramă cooperativă, trebuie să existe o relație între ele.

Există patru tipuri de relații care pot fi stabilite între clase: asocieri, dependențe, agregare și generalizări.

Asociația de Comunicare

Asocierea este o conexiune semantică între clase. Ele sunt desenate pe diagrama de clasă ca o linie obișnuită.

Orez. 10. Asociația de Comunicare

Asociațiile pot fi bidirecționale, ca în exemplu, sau unidirecționale. În UML, asociațiile bidirecționale sunt desenate ca o linie simplă fără săgeți sau cu săgeți pe ambele părți. O asociere unidirecțională are o singură săgeată care arată direcția sa.

Direcția de asociere poate fi determinată examinând diagramele secvențe și diagramele cooperative. Dacă toate mesajele de pe ele sunt trimise doar de o clasă și primite doar de o altă clasă, dar nu și invers, există o comunicare unidirecțională între aceste clase. Dacă cel puțin un mesaj este trimis către reversul, asocierea trebuie să fie bidirecțională.

Asociațiile pot fi reflexive. Asocierea reflexivă presupune că o instanță a unei clase interacționează cu alte instanțe ale aceleiași clase.

Dependența de comunicare

Relațiile de dependență reflectă și relațiile dintre clase, dar ele sunt întotdeauna unidirecționale și arată că o clasă depinde de definițiile făcute în alta. De exemplu, clasa A folosește metode din clasa B. Apoi, atunci când clasa B se schimbă, este necesar să se facă modificări corespunzătoare în clasa A.

Este descrisă dependența linie punctată desenat între două elemente ale diagramei, iar elementul atașat la capătul săgeții este considerat a depinde de elementul atașat la începutul acestei săgeți.

Orez. 11. Dependenta de comunicare

Când se generează cod pentru aceste clase, nu li se vor adăuga atribute noi. Cu toate acestea, vor fi creați operatori specifici limbii pentru a sprijini comunicarea.

Agregarea comunicării

Agregările sunt o formă mai strânsă de asociere. Agregarea este o legătură între întreg și partea sa. De exemplu, este posibil să aveți o clasă numită Mașină, precum și clase precum Motor, Anvelope și clase pentru alte părți ale mașinii. Ca rezultat, un obiect din clasa Mașină va consta dintr-un obiect din clasa Engine, patru obiecte Tire etc. Agregările sunt vizualizate ca o linie cu un romb în apropierea clasei, care este un număr întreg:

Orez. 11. Agregarea comunicării

Pe lângă agregarea simplă, UML introduce un tip mai puternic de agregare numit compoziție. Conform compoziției, un obiect-parte poate aparține doar unui singur întreg și, în plus, de regulă, ciclul de viață al părților coincide cu ciclul întregului: ele trăiesc și mor odată cu el. Orice ștergere a întregului se aplică părților sale.

Această ștergere în cascadă este adesea considerată ca parte a definiției agregării, dar este întotdeauna implicită atunci când multiplicitatea rolului este 1..1; de exemplu, dacă este necesară ștergerea unui Client, atunci această ștergere trebuie să se aplice și Comenzilor (și, la rândul lor, liniilor de comandă).

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 oferi acord complet în notația grafică folosită pentru a reprezenta concepte comune, cum ar fi: componentă, generic, clasă, comportament și agregare. Datorită acestui fapt, se atinge 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 în acest caz, O diagramă de clasă UML descrie un model al unui domeniu specific și oferă doar clase de obiecte de aplicație.
• Specific. Diagrama este utilizată în procesul de proiectare a diferitelor sisteme informaționale.
• Implementarea. Diagrama de clase include tot felul de clase care sunt utilizate direct în codul programului.

Diagrama componentelor

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

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

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

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ă de caz de utilizare UML descrie toate relațiile care apar între actori, precum și diverse opțiuni 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.
• 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 descriere detaliată funcționalitatea acestui sistem.

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, cu gradul de precizie necesar, vă puteți converti unul în altul.

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 Dispune de un format complet gratuit pentru aranjarea mai multor obiecte și conexiuni în același mod ca î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 desemnările diferitelor obiecte, precum și liniile verticale care înfățișează trecerea timpului și dreptunghiurile 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 transmiterii 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 secvență dintr-o diagramă de comunicare sau invers și, de asemenea, le sincronizează complet automat.

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.

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ă varianta alternativa diagramă de secvență, care demonstrează clar schimbarea stării de-a lungul unei linii de viață cu o anumită scară de timp. Poate fi destul de util în diverse aplicații î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 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 precis 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. Inexactitatea în specificațiile limbajului în sine afectează atât utilizatorii, cât și vânzătorii de instrumente, ceea ce duce în cele din urmă la incompatibilitatea instrumentelor din cauza modului unic de tratare a diferitelor specificații.
• Probleme în procesul de implementare și studiu. Toate problemele de mai sus creează provocări în implementarea și învățarea UML, mai ales atunci când managementul îi obligă pe ingineri să îl folosească fără cunoștințe prealabile.
• 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 î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 scop general, care încearcă să asigure compatibilitatea cu orice limbaj de procesare existent î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.

Adnotare: Subiectul acestui curs este UML - limbajul unificat de modelare. Conferința anterioară a vorbit despre ce este UML, istoria sa, scopul, modurile de utilizare a limbajului, structura definiției sale, terminologia și notația. Sa observat că un model UML este un set de diagrame. În această prelegere vom lua în considerare următoarele întrebări: de ce sunt necesare mai multe tipuri de diagrame; tipuri de diagrame; OOP și secvență de diagramă

Înainte de a trece la discutarea materialului principal al acestei prelegeri, să vorbim despre motivul pentru care trebuie să construim orice diagramă. Dezvoltarea unui model al oricărui sistem (nu doar software) precede întotdeauna crearea sau actualizarea acestuia. Acest lucru este necesar cel puțin pentru a ne imagina mai clar problema rezolvată. Modelele bine gândite sunt foarte importante atât pentru interacțiunea în cadrul echipei de dezvoltare, cât și pentru înțelegerea reciprocă cu clientul. În cele din urmă, acest lucru asigură că designul este „consecvent din punct de vedere arhitectural” înainte de a fi implementat în cod.

Construim modele de sisteme complexe pentru că nu le putem descrie complet, „aruncă o privire la ele dintr-o privire”. Prin urmare, evidențiem doar proprietățile sistemului care sunt esențiale pentru o anumită sarcină și construim modelul acestuia care afișează aceste proprietăți. Metoda analizei orientate pe obiecte ne permite să descriem sisteme complexe reale în cel mai adecvat mod. Dar, pe măsură ce complexitatea sistemelor crește, apare nevoia unei bune tehnologii de modelare. După cum am spus deja în prelegerea anterioară, un unit limbaj de modelare(Unified Modeling Language, UML), care este un limbaj grafic pentru specificarea, vizualizarea, proiectarea și documentarea sistemelor. Folosind UML puteți dezvolta model detaliat a sistemului creat, reflectând nu numai conceptul său, ci și caracteristicile specifice implementării acestuia. În cadrul modelului UML, toate ideile despre sistem sunt înregistrate sub forma unor structuri grafice speciale numite diagrame.

Nota. Vom lua în considerare nu toate, ci doar câteva dintre tipurile de diagrame. De exemplu, diagrama componentelor nu este tratată în această prelegere, care este doar o scurtă prezentare generală a tipurilor de diagrame. Numărul de tipuri de diagrame pentru model specific aplicațiile nu sunt limitate în niciun fel. Pentru aplicații simple nu este nevoie să construiți diagrame de toate tipurile fără excepție. Unele dintre ele pot lipsi pur și simplu, iar acest fapt nu va fi considerat o eroare. Este important să înțelegeți că disponibilitatea anumitor tipuri de diagrame depinde de specificul unui anumit proiect. Informații despre alte tipuri de diagrame (nu sunt discutate aici) pot fi găsite în standardul UML.

De ce aveți nevoie de mai multe tipuri de diagrame

Mai întâi, să definim terminologia. În introducerea acestei prelegeri am folosit în mod repetat conceptele de sistem, model și diagramă. Autorul este încrezător că fiecare dintre noi înțelege în mod intuitiv sensul acestor concepte, dar pentru a fi complet clar, să ne uităm din nou la glosar și să citim următoarele:

Sistem- un set de subsisteme controlate interconectate unite printr-un scop comun de operare.

Da, nu prea informativ. Ce este atunci un subsistem? Pentru a clarifica situația, să ne întoarcem la clasici:

Sistem se referă la un set de subsisteme organizate pentru a atinge un scop specific și descrise folosind un set de modele, eventual din puncte de vedere diferite.

Ei bine, nu poți face nimic, va trebui să cauți o definiție a unui subsistem. Se mai spune acolo că subsistem este o colecție de elemente, dintre care unele specifică comportamentul altor elemente. Ian Sommerville explică acest concept astfel:

Subsistemul este un sistem a cărui funcționare nu depinde de serviciile altor subsisteme. Sistemul software este structurat ca o colecție de subsisteme relativ independente. Sunt definite și interacțiunile dintre subsisteme.

De asemenea, nu este foarte clar, dar este mai bine. Vorbind în limbaj „uman”, sistemul este reprezentat ca un set de entități mai simple care sunt relativ autosuficiente. Acest lucru poate fi comparat cu modul în care construim în procesul de dezvoltare a unui program GUI din „cuburi” standard - componente vizuale, sau modul în care textul programului în sine este, de asemenea, împărțit în module care conțin subrutine, unite prin funcționalitate, și pot fi reutilizate în programele ulterioare.

Înțelegem conceptul de sistem. În timpul procesului de proiectare, sistemul este luat în considerare din puncte de vedere diferite cu ajutorul unor modele ale căror diferite reprezentări apar sub formă de diagrame. Din nou, cititorul poate avea întrebări despre semnificația conceptelor modeleŞi diagrame. Credem că este o definiție frumoasă, dar nu foarte clară modele ca o abstractizare închisă semantic a sistemului Este puțin probabil să clarificăm situația, așa că vom încerca să explicăm „în propriile noastre cuvinte”.

Model- acesta este un anumit obiect (material sau nu) care afișează doar cele mai semnificative caracteristici ale sistemului pentru o anumită sarcină. Modelele sunt diferite - materiale și intangibile, artificiale și naturale, decorative și matematice...

Să dăm câteva exemple. Mașinile de jucărie din plastic cunoscute tuturor, cu care ne-am jucat cu atâta entuziasm în copilărie, nu sunt altceva decât material decorativ artificial modelul unei mașini adevărate. Desigur, o astfel de „mașină” nu are motor, nu-i umplem rezervorul cu benzină, iar cutia de viteze nu funcționează (într-adevăr, nu există nicio cutie de viteze), dar ca model această jucărie își îndeplinește complet funcțiile : îi oferă copilului o idee despre mașină, deoarece își arată trăsăturile caracteristice sunt prezența a patru roți, o caroserie, uși, geamuri, capacitatea de a conduce etc.

În cercetarea medicală, testarea pe animale precede adesea studiile clinice pe oameni. În acest caz, animalul acționează ca material natural modele umane.

Ecuația descrisă mai sus este, de asemenea, un model, dar este un model matematic și descrie mișcarea unui punct material sub influența gravitației.

Tot ce rămâne este să spunem ce este o diagramă. Diagramă este o reprezentare grafică a multor elemente. În mod obișnuit, este reprezentat ca un grafic cu vârfuri (entități) și muchii (relații). Există multe exemple de diagrame. Aceasta este o diagramă bloc familiară tuturor din anii de școală și diagrame de instalare pentru diverse echipamente, pe care le putem vedea în manualele de utilizare, și un arbore de fișiere și directoare de pe disc, pe care le putem vedea rulând comanda tree în Consolă Windows și multe, multe altele. ÎN viata de zi cu zi diagramele ne înconjoară din toate părțile, pentru că percepem desenele mai ușor decât textul...

Dar să revenim la designul software (și mai mult). În această industrie cu Diagramele pot fi folosite pentru a vizualiza un sistem din perspective diferite. Una dintre diagrame, de exemplu, poate descrie interacțiunea utilizatorului cu sistemul, alta poate descrie schimbarea stărilor sistemului în timpul funcționării acestuia, a treia poate descrie interacțiunea elementelor sistemului între ele etc. Un sistem complex poate și ar trebui să fie reprezentat ca un set de modele mici și aproape independente - diagrame, și niciuna dintre ele nu este suficientă pentru a descrie sistemul și a obține o imagine completă a acestuia, deoarece fiecare dintre ele se concentrează pe un aspect specific al funcționării sistemului și exprimă un diferit nivelul de abstractizare. Cu alte cuvinte, fiecare model corespunde unui anumit punct de vedere specific asupra sistemului proiectat.

În ciuda faptului că în paragraful anterior am tratat foarte liber conceptul de model, trebuie înțeles că în contextul definițiilor de mai sus nicio diagramă individuală nu este un model. Diagramele sunt doar un mijloc de vizualizare a unui model, iar cele două concepte trebuie distinse. Numai un set de diagrame alcătuiește un model de sistemși o descrie cel mai complet, dar nu doar o diagramă scoasă din context.

Tipuri de diagrame

UML 1.5 definit douăsprezece tipuri de diagrame, împărțit în trei grupe:

• patru tipuri de diagrame reprezintă structura statică a aplicației;
• cinci reprezintă aspecte comportamentale ale sistemului;
• trei reprezintă aspectele fizice ale funcționării sistemului (diagrame de implementare).

Versiunea actuală a UML 2.1 nu a făcut prea multe modificări. Diagramele s-au modificat ușor în aspect (au apărut cadre și alte îmbunătățiri vizuale), notația a fost ușor îmbunătățită, iar unele diagrame au primit denumiri noi.

Cu toate acestea, numărul exact diagrame canonice pentru noi este absolut lipsit de importanță, deoarece nu le vom lua în considerare pe toate, ci doar pe unele - pentru că numărul de tipuri de diagrame pentru un anumit model al unei anumite aplicații nu este strict fixat. Pentru aplicații simple nu este nevoie să construiți fiecare diagramă. De exemplu, pentru o aplicație locală nu este necesară construirea unei diagrame de implementare. Este important să înțelegeți că lista de diagrame depinde de specificul proiectului în curs de dezvoltare și este determinată de dezvoltatorul însuși. Dacă cititorul curios mai vrea să afle despre toate diagramele UML, îl vom trimite la standardul UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Să vă reamintim că scopul acestui curs nu este de a descrie absolut toate capacitățile UML, ci doar de a introduce acest limbaj și de a oferi o idee inițială despre această tehnologie.

Deci, ne vom uita pe scurt la astfel de tipuri de diagrame precum:

• diagrama cazului de utilizare;
• diagrama de clase;
• diagrama obiectului;
• diagrama secventa;
• diagrama de interacțiune;
• diagrama de stare;
• diagrama de activitate;
• diagrama de implementare.

Despre unele dintre aceste diagrame vom vorbi mai detaliat în prelegerile viitoare. Deocamdată, nu ne vom concentra asupra detaliilor, ci ne vom stabili scopul de a-l învăța pe cititor să distingă cel puțin vizual între tipurile de diagrame și să dăm o idee inițială despre scopul principalelor tipuri de diagrame. Deci să începem.

Diagrama de caz de utilizare

Orice sisteme (inclusiv software) sunt proiectate ținând cont de faptul că în timpul funcționării lor vor fi utilizate de oameni și/sau vor interacționa cu alte sisteme. Sunt apelate entitățile cu care sistemul interacționează în timpul funcționării sale actoriși fiecare actor se așteaptă ca sistemul să se comporte într-un mod strict definit, previzibil. Să încercăm să dăm o definiție mai strictă a unui ector. Pentru a face acest lucru, vom folosi un dicționar vizual minunat pentru UML Zicom Mentor:

Ector (actor)- acesta este un set de roluri legate logic îndeplinite atunci când interacționează cu precedente sau entități (sistem, subsistem sau clasă). Un actor poate fi o persoană sau un alt sistem, subsistem sau clasă care reprezintă ceva în afara entității.

Grafic, ectorul este reprezentat fie " omuleț„, asemănătoare celor pe care le desenam în copilărie, înfățișând membrii familiei noastre, sau simbolul clasei cu stereotipul corespunzător așa cum se arată în imagine. Ambele forme de reprezentare au aceeași semnificație și pot fi folosite în diagrame. Forma „stereotipată” este folosită mai des pentru a reprezenta actorii sistemului sau în cazurile în care un actor are proprietăți și acestea trebuie afișate (Fig. 2.1).

Un cititor atent poate întreba imediat: de ce un actor și nu un actor? Suntem de acord, cuvântul „ektor” este puțin aspru pentru urechile rușilor. Motivul pentru care spunem acest lucru este simplu - ector este derivat din cuvânt acţiune, care a tradus înseamnă acţiune. Traducerea literală a cuvântului „ector” este caracter- prea lung și incomod de utilizat. Prin urmare, vom continua să vorbim în acest fel.

Același cititor atent ar fi putut observa că cuvântul „precedent” trece prin definiția actorului. Ce este asta? Această întrebare ne va interesa și mai mult dacă ne amintim despre care vorbim acum diagrama cazului de utilizare. Aşa,

Caz de utilizare- descrierea unui aspect separat al comportamentului sistemului din punctul de vedere al utilizatorului (Butch).

Definiția este destul de clară și cuprinzătoare, dar poate fi clarificată în continuare folosind aceeași Zicom Mentor"om:

Caz de utilizare- o descriere a unui set de evenimente secvențiale (inclusiv opțiuni) efectuate de sistem care conduc la rezultatul observat de actor. Un caz de utilizare reprezintă comportamentul unei entități, descriind interacțiunea dintre actori și sistem. Un caz de utilizare nu arată „cum” se obține un anumit rezultat, ci doar „ce” se realizează.

Precedentele sunt desemnate într-un mod foarte simplu - sub forma unei elipse, în interiorul căreia este indicat numele său. Cazurile de utilizare și actorii sunt conectați folosind linii. Adesea, o figură este desenată la un capăt al liniei. 2.3

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 software-ului bazat pe abordarea OO, pentru a organiza relația dintre conceptele conceptuale și de program și pentru a reflecta problemele de scalare a sistemelor complexe. Modelele UML sunt utilizate în toate etapele ciclului de viață al software-ului, de la analiza afacerii până la întreținerea sistemului. Diferite organizații pot utiliza UML după cum consideră de cuviință, în funcție de zonele lor problematice și de tehnologiile pe care le folosesc.

O scurtă istorie a UML

Până la mijlocul anilor '90, diverși autori au propus câteva zeci de metode de modelare OO, fiecare dintre ele folosind propria sa notație grafică. Mai mult, fiecare dintre aceste metode avea propriile sale metode punctele forte, dar nu ne-a permis să construim un model suficient de complet al PS, să-l arătăm „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 adoptarea pe scară largă a abordării OO pentru dezvoltarea de 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 Butch, D. Rambo și A. Jacobson, care au combinat eforturile, au creat versiunea UML 1.1, 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 crea construcții semnificative. Acesta este, în special, modul în care sunt structurate limbajele 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 clar de către altul și, de asemenea, software, interpretând UML. De aici, în special, rezultă că un model de software 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 suportă UML, având construit modelul, vom primi și semifabricatul codul programului, corespunzător acestui model.

Trebuie subliniat faptul că UML este un limbaj, nu o metodă. Acesta explică din ce elemente să creați modele și cum să le citiți, 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.

Dicţionar UML

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

Entități sunt abstractizări care sunt elementele principale ale modelelor. Există patru tipuri de entități - structurale (clasă, interfață, componentă, caz de utilizare, colaborare, nod), comportamentală (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 se studiază diagramele.

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

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

Diagrame. UML oferă următoarele diagrame:

• Diagrame care descriu comportamentul sistemului:
• Diagrame de stări
• Diagrame de activitate,
• Diagramele obiectelor,
• Diagrame secvențe,
• Diagrame de colaborare;
• Diagrame care descriu implementarea fizică a sistemului:
• Diagrame componente;
• Diagrame de implementare.

Vedere de control model. Pachete.

Am spus deja că pentru ca un model să fie bine înțeles de oameni 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 conține alte pachete, permițând crearea de ierarhii. UML nu furnizează diagrame de pachete separate, dar acestea pot apărea în alte diagrame. Pachetul este reprezentat ca un dreptunghi cu un marcaj.

Ce oferă UML.

• descriere ierarhică sistem complex prin alocarea pachetelor;
• formalizarea cerințelor funcționale pentru sistem folosind aparatul de cazuri de utilizare;
• detalierea cerințelor sistemului prin construirea de diagrame de activitate și scenarii;
• identificarea claselor de date și construirea unui model conceptual de date sub formă de diagrame de clasă;
• identificarea claselor care descriu interfata utilizatorși crearea unei scheme de navigare pe ecran;
• descrierea proceselor de interacțiune a obiectelor la îndeplinirea funcțiilor sistemului;
• descrierea comportamentului obiectului sub formă de diagrame de activitate și stare;
• descrierea componentelor software și interacțiunea acestora prin interfețe;
• descrierea arhitecturii fizice a sistemului.

Și ultimul lucru...

În ciuda tuturor atractivității UML, ar fi dificil de utilizat î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 șabloane de cod de program î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 automata codurile sursă ale programelor, ceea ce este foarte important pentru a asigura conformitatea dintre model și coduri și atunci când se proiectează sisteme care moștenesc funcționalitatea sistemelor predecesoare.

UML (Unified Modeling Language) este un limbaj de descriere grafică pentru modelarea obiectelor în domeniul dezvoltării software. UML este un limbaj general, un standard deschis care folosește notația grafică pentru a crea un model abstract al unui sistem, numit model UML. UML a fost creat pentru a defini, vizualiza, proiecta și documenta în 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

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

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

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

%0A

Microsoft%20Visual%20Studio%202010

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

%0A

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

%0A

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

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

%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:

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

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

IBM Rational Rose

Posibilitati:

• Diagrama cazului 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)
• Plug-in Architecture (puteți scrie în limbi compatibile COM: C++, Delphi, C#, VB, ...)

StarUML este scris în principal în Delphi, dar componentele pot fi scrise și în alte limbi, de exemplu C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Mai jos sunt câteva capturi de ecran.

Diagrama de clasa:

Diagrama cazului de utilizare:

ArgoUML

Diagrame acceptate:

• Clasă
• Stat
• Caz de utilizare
• Activitate
• Colaborare
• Desfăşurare
• Secvenţă

Posibilitati:

• Suportă 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: