Caracteristici ale imaginilor cu diagramă UML

Pentru diagramele UML, există trei tipuri de simboluri grafice vizuale care sunt importante în ceea ce privește informațiile pe care le conțin:

· Figuri geometrice pe plan, jucând rolul de vârfuri ale graficelor diagramelor corespunzătoare. În acest caz, figurile geometrice în sine acționează ca primitive grafice ale limbajului UML, iar forma acestor figuri (dreptunghi, elipsă) trebuie să corespundă strict imaginii elementelor individuale ale limbajului UML (clasă, caz de utilizare, stare, activitate). ). Primitivele grafice UML au o semantică fixă pe care utilizatorii nu au voie să o înlocuiască. Primitivele grafice trebuie să aibă propriile nume și, eventual, alt text, care este conținut în limitele formelor geometrice corespunzătoare sau, ca excepție, în apropierea acestor forme.

· Relații grafice care sunt reprezentate prin diferite linii pe un plan. Relații în Limbajul UML generalizează conceptul de arce și muchii din teoria grafurilor, dar au un caracter mai puțin formal și o semantică mai dezvoltată.

· Simboluri grafice speciale reprezentate în apropierea anumitor elemente vizuale ale diagramelor și având natura unor specificații suplimentare (decorări).

Toate diagramele în limbajul UML sunt reprezentate folosind figuri pe un plan. Elemente separate - folosind forme geometrice care pot avea diferite înălțimi și lățimi pentru a acomoda alte constructe ale limbajului UML în interiorul lor. Cel mai adesea, liniile de text sunt plasate în interiorul unor astfel de simboluri, care clarifică semantica sau captează proprietățile individuale ale elementelor corespunzătoare ale limbajului UML. Informațiile conținute în forme au sens pentru model specific a sistemului proiectat, deoarece reglementează implementarea elementelor corespunzătoare din codul programului.

Căile sunt secvențe de segmente de linie care conectează simboluri grafice individuale. În acest caz, punctele de capăt ale segmentelor de linie trebuie să fie neapărat în contact cu forme geometrice, care servesc la desemnarea vârfurilor diagramelor, așa cum este obișnuit în teoria grafurilor. Din punct de vedere conceptual, căile sunt accentuate în UML deoarece sunt simple entități topologice. Părțile sau segmentele de cale individuale pot să nu existe în afara căii care le conține. Căile ating întotdeauna alte simboluri grafice pe ambele granițe ale segmentelor de linie corespunzătoare, de ex. traseele nu se pot termina pe diagramă cu o linie care nu atinge niciun simbol grafic. După cum sa menționat mai sus, căile pot avea o figură grafică specială ca final sau terminator - o pictogramă care este reprezentată la unul dintre capetele liniilor.

Pictogramele sau decorațiunile suplimentare sunt forme grafice de dimensiune și formă fixă. Nu își pot crește dimensiunea pentru a găzdui caractere suplimentare. Pictogramele sunt plasate atât în interiorul, cât și în exteriorul altor design-uri grafice. Exemplele de pictograme includ terminațiile conexiunilor elementelor de diagramă sau denumirile grafice ale cuantificatorilor de vizibilitate pentru atribute și operații de clasă.

Diagrama de cooperare

Diagramele de cooperare sunt concepute pentru a descrie aspectele dinamice ale sistemului care este modelat. Ele sunt de obicei folosite pentru:

· arătați un set de obiecte care interacționează într-un mediu real „din ochi de pasăre”;

· distribuirea funcționalității între clase pe baza rezultatelor studierii aspectelor dinamice ale sistemului;

· descrie logica de execuție operatii complexe, mai ales în cazurile în care un obiect interacționează cu mai multe alte obiecte;

· studiază rolurile îndeplinite de obiecte în cadrul sistemului, precum și relațiile dintre obiectele în care acestea sunt implicate în îndeplinirea acestor roluri.

Când vorbim despre diagrame de cooperare, sunt adesea menționate două „niveluri” ale unor astfel de diagrame:

· nivel de instanță(exemple, Instance-Level): afișează interacțiunile dintre obiecte (instanțele de clasă); ca aceasta diagramă create de obicei pentru a explora organizare internă sistem orientat pe obiecte.

· nivelul de specificație(Specification-Level): folosit pentru a studia rolurile îndeplinite de principalele clase din sistem.

Acesta arată interacțiunea dintre obiecte, care se realizează prin trimiterea și primirea de mesaje.

Diagrama componentelor

Componentele sunt conectate prin dependențe atunci când o interfață necesară a unei componente este conectată la o interfață existentă a altei componente. Aceasta ilustrează relația client-sursă dintre cele două componente.

O dependență indică faptul că o componentă oferă un serviciu cerut de o altă componentă. Dependența este reprezentată de o săgeată de la interfața client sau portul către interfața importată.

Principalul tip de entități dintr-o diagramă de componente sunt componentele în sine 1, precum și interfețele 2, prin care este indicată relația dintre componente. Următoarele relații se aplică într-o diagramă de componente:

· implementari intre componente si interfete (componenta implementeaza interfata);

· dependențe între componente și interfețe (componenta folosește interfața) 3.

Diagrama de implementare

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

O diagramă de implementare conține reprezentări grafice ale procesoarelor, dispozitivelor, proceselor și conexiunilor dintre ele. Spre deosebire de diagramele de reprezentare logică, o diagramă de implementare este uniformă pentru sistemul în ansamblu, deoarece trebuie să reflecte pe deplin caracteristicile implementării sale. Dezvoltarea unei diagrame de implementare este de obicei ultimul pas în specificarea modelului sistem software.

La elaborarea unei diagrame de implementare, sunt urmărite următoarele obiective:

· determina distribuția componentelor sistemului în nodurile sale fizice;

· spectacol conexiuni fiziceîntre toate nodurile implementării sistemului în etapa de execuție a acestuia;

· identificați blocajele sistemului și reconfigurați topologia acestuia pentru a obține performanța necesară.

15.2. Scopul și alcătuirea diagramei componentelor

O diagramă de componente vă permite să determinați compoziția componentelor software, care pot fi cod sursă, binar și executabil, precum și să stabiliți dependențe între ele.

La elaborarea diagramelor componentelor, obiectivele sunt:

Specificație structura generala cod sursa sisteme;

Specificarea unei versiuni executabile a sistemului.

Această diagramă oferă o tranziție consistentă de la reprezentarea logică la cea fizică a sistemului sub formă de componente software. Unele componente pot exista doar în timpul compilării codul programului, altele - în stadiul executării acestuia. Elementele principale ale diagramei sunt componentele, interfețele și dependențele dintre ele. În plus, poate afișa clasele cheie incluse în componente.

Componentă (componenta engleză) este o parte fizică a sistemului. Componente, care sunt fișiere cu codul sursă al claselor, biblioteci, module executabile etc., care trebuie să aibă un set consistent de interfețe. Pentru a lor reprezentare grafică Sunt utilizate următoarele simboluri grafice.

Orez. 15.2. Exemple de componente

In interiorul dreptunghiului este scris numele componentei si eventual cateva Informații suplimentare ca valoare etichetată.

Componentele pot avea următoarele stereotipuri standard:

- „fișier” – orice fișier cu excepția unui tabel:

o „executable” – program (fișier executabil);

o „bibliotecă” – bibliotecă statică sau dinamică;

o „sursă” – fișier cu textul sursă al programului;

o „document” – alte fișiere (de exemplu, un fișier de ajutor);

- „tabel” – tabelul bazei de date.

În interiorul unei componente, cum ar fi o clasă, poate fi alocată secțiuni suplimentare, care indică interfețele și clasele furnizate sau necesare pentru funcționare, metode (operații), numele fișierului componente (artefacte) etc.

Orez. 15.3. Componenta Sectionala

Interfață (Interfața în limba engleză) este un set de operațiuni vizibil extern, numit, pe care o clasă, componentă sau subsistem le poate furniza unei alte clase, componente sau subsistem pentru a-și îndeplini funcțiile. În unele limbaje de programare, în special în Java, o interfață este o clasă separată care este inclusă și implementată (concretizat) într-o parte a codului de operații al programului ca parte a altor clase. Pe diagrama componentelor interfața este afișată la fel ca și pe (în stânga componentei sunt interfețele necesare funcționării, în dreapta sunt interfețele prevăzute).

Orez. 15.4. Metode de afișare a interfeței

Relația de asociere afișate între componente și interfețele acestora. Relație de dependență înseamnă dependența implementării unor componente de implementarea altora. Acest lucru este posibil în următoarele cazuri:

În metodele claselor unei componente (dependente), metodele sunt numite sau accesul la atributele claselor unei alte componente (independente);

O componentă constă din alte componente (de exemplu, la asamblarea unui fișier executabil din fișiere de cod sursă);

O componentă citește sau scrie date pe o altă componentă;

Relația dintre tabelele bazei de date;

Datorită scopului multifuncțional al unei diagrame de componente, următoarele reguli și recomandări ar trebui urmate la elaborarea acesteia.

1. Înainte de a dezvolta diagramele componente, este necesar să se decidă din ce părți fizice (fișiere) va consta sistemul software. În acest caz, trebuie rezolvate două probleme - distribuția claselor între fișierele de cod sursă și între subsisteme. În acest din urmă caz, distribuirea claselor în pachete specializate (specifice domeniului funcțional) poate ajuta. În această etapă, ar trebui să se acorde atenție unei astfel de implementări a sistemului care ar oferi capacitatea reutilizare codifică prin descompunerea rațională a sistemului, adică minimizarea numărului de conexiuni între componente.

2. La precizarea structurii generale a codului sursă al sistemului este necesar să se țină cont de specificul limbajului de programare cu care sunt implementate componentele. În special, în Java se recomandă să descrieți o clasă separată într-un fișier separat, în ciuda faptului că limbajul vă permite să descrieți mai multe clase într-un fișier și să utilizați mecanismul claselor interne. Diagrama componentelor utilizată în scopul în cauză este prezentată în figura următoare.

Orez. 15.5. Fragment dintr-o diagramă de componente care specifică structura codului sursă

Diagrama din fig. 15.5 arată compoziția claselor (fișierelor) care alcătuiesc componenta executabilă iskraPUT.jar, precum și dependențele dintre clase.

3. Pentru a specifica o versiune executabilă a sistemului, este necesar să existe o topologie preliminară a sistemului, adică o schiță. Pentru fiecare nod din rețea se poate construi o diagramă de componente care definește setul de fișiere necesare funcționării subsistemului (subsistemelor) la un loc de muncă separat.

Orez. 15.6. Exemplu de diagramă de componente care specifică compoziția componentelor la locul de muncă al unui utilizator

4. Diagrama poate reprezenta relaţiile de dependenţă dintre componente şi clasele pe care le conţin. Aceste informații sunt esențiale pentru a asigura coerența între reprezentările logice și fizice ale sistemului. În acest caz, dependența poate fi arătată în două moduri:

Afișați clasele separat de componentă și asociați componenta cu fiecare clasă cu o relație de dependență. De exemplu, în Fig. 15.5, în loc de componente cu extensia „java”, arată clasele corespunzătoare;

Afișează clase în interiorul simbolului componentei.

6. Pentru a afișa vizual specificul componentelor, puteți utiliza stereotipuri grafice în locul unui simbol de componentă standard cu un stereotip șir în interior.

Afișați defalcarea unui sistem software în componente structurale și conexiuni (dependențe) între componente.

Componentele fizice pot fi fișiere, biblioteci, module, fișiere executabile, pachete etc.

Plan de acțiune

După ce ați citit secțiunile (Exemplu, Aplicație), puteți încerca să creați singur diagramele componente.

Cum se aplică metoda de proiectare

Diagramele componentelor trebuie utilizate atunci când un sistem este împărțit în componente și relațiile acestora trebuie afișate prin interfețe sau o diagramă a componentelor din structura de nivel inferior a sistemului.

Exemplu de utilizare

Există dezbateri în comunitatea orientată pe obiect cu privire la ceea ce constituie diferența dintre clasa componentă și cea obișnuită. Nu vom discuta despre asta aici problema controversata, dar va arăta notația UML folosită pentru a le distinge unul de celălalt.

UML 1 avea un simbol separat pentru o componentă (Figura 14.1). ÎN UML 2 Această pictogramă nu este prezentă, dar puteți desemna dreptunghiul de clasă cu o pictogramă similară. Sau poți folosi cuvânt cheie « componentă» ( componentă).

În afară de această pictogramă, componentele nu au adus cu ele nicio denumire nouă. Componentele comunică între ele utilizând interfețele furnizate sau necesare, cu notația bilă și soclu folosită de obicei doar în diagramele de clasă. De asemenea, puteți defalca componente folosind diagrame de structură a componentelor.

În fig. Figura 14.2 prezintă un exemplu de diagramă simplă a componentelor. În acest exemplu componenta Till (casier) poate interacționa cu componenta Server de vânzări folosind interfața mesaj de vânzare. Deoarece rețeaua nu este de încredere, componenta Coada de mesaje instalat astfel încât casa de marcat să poată vorbi cu serverul atunci când rețeaua rulează și să vorbească cu coada de mesaje când rețeaua este oprită. Apoi, coada de mesaje poate vorbi cu serverul când rețeaua devine din nou disponibilă. Ca rezultat, coada de mesaje oferă o interfață pentru a vorbi cu casa de marcat și necesită aceeași interfață pentru a vorbi cu serverul. Serverul este împărțit în două componente principale: Procesorul de tranzacții implementează interfața de mesaje și Sofer de contabilitate comunică cu Sistem de contabilitate.

Întrebarea esenței unei componente este subiectul unei dezbateri nesfârșite. Iată una dintre cele mai atente afirmații pe care le-am găsit:

Componentele nu sunt tehnologie. Tehnicienilor le este greu de înțeles. Componentele sunt mai mult un stil de relație cu clienții software. Vor să poată cumpăra software-ul de care au nevoie în bucăți și, de asemenea, să-l poată face upgrade așa cum își actualizează sistemul stereo. Ei doresc ca noile componente să funcționeze la fel de bine ca cele vechi și să le actualizeze conform planurilor lor, nu conform instrucțiunilor producătorilor. Ei vor sisteme diverși producători puteau lucra împreună și erau interschimbabile. Acestea sunt cerințe foarte rezonabile. O singură captură: sunt greu de completat.
Ralph Johnson, http://www.c2.com/cgi/wiki?DoComponentsExist

Important este că componentele reprezintă elemente care pot fi achiziționate și modernizate independent. Ca urmare, împărțirea sistemului în componente este mai mult o decizie de marketing decât una tehnică. Ghid excelent pentru această problemă prezintă cartea lui Hochman. De asemenea, ne reamintește să ne ferim să împărțim sistemul în componente prea mici, deoarece foarte o cantitate mare componentele sunt greu de gestionat, mai ales când versiunea își ridică capul urât; de aici vine expresia „DLL infern” sau „dll infern”. În versiunile timpurii ale UML, componentele erau folosite pentru a reprezenta structuri fizice, cum ar fi DLL-urile. Acest lucru nu mai este relevant; În prezent această problemă este rezolvată folosind artefacte(artefacte).

Abonați-vă la știrile site-ului; puteți găsi formularul de abonare în coloana din dreapta site-ului.

Dacă vrei să înveți să lucrezi ca freelancer profesional, te invităm la cursul „”.

O diagramă de componente, spre deosebire de diagramele discutate anterior, descrie caracteristicile reprezentării fizice a sistemului. Diagrama componentelor - o diagramă structurală statică care arată împărțirea unui sistem software în componente structurale și conexiuni (dependențe) între componente.

Aceasta ilustrează relația client-sursă dintre cele două componente. După ce ați citit secțiunile (Exemplu, Aplicație), puteți încerca să creați singur diagramele componente. Există dezbateri în comunitatea orientată pe obiecte despre care este diferența dintre o componentă și o clasă obișnuită. UML 1 avea un simbol separat pentru o componentă (Figura 14.1). UML 2 nu are această pictogramă, dar puteți desemna un dreptunghi de clasă cu o pictogramă similară.

În acest exemplu, componenta Till poate comunica cu componenta Sales Server folosind interfața de mesaje de vânzări. Întrebarea esenței unei componente este subiectul unei dezbateri nesfârșite. Componentele nu sunt tehnologie. Componentele sunt mai mult o modalitate pentru clienți de a se raporta la software. Ei doresc ca noile componente să funcționeze la fel de bine ca cele vechi și să le actualizeze conform planurilor lor, nu conform instrucțiunilor producătorilor.

În timpul procesului de proiectare, un arhitect sau un programator experimentat creează documentație de proiectare, inclusiv descrieri de text, diagrame și modele ale viitorului program. UML este un limbaj grafic pentru vizualizare, descrierea parametrilor, proiectare și documentare diverse sisteme(programe în special).

O diagramă de clasă servește pentru a reprezenta structura statică a unui model de sistem în terminologia claselor de programare orientată pe obiecte. Din acest punct de vedere, diagrama de clase este o dezvoltare ulterioară a modelului conceptual al sistemului proiectat. Pentru a modela interacțiunea obiectelor în limbajul UML, sunt utilizate diagrame de interacțiune adecvate.

În diagrama de cooperare, obiectele care participă la interacțiune sunt reprezentate sub formă de dreptunghiuri, conținând numele obiectului, clasa acestuia și, eventual, valorile atributelor. Spre deosebire de diagrama de secvență, o diagramă de cooperare descrie doar relațiile dintre obiecte care joacă roluri specifice în interacțiune. În acest caz, sunt reprezentate doar componentele instanței de program, care sunt fișiere executabile sau biblioteci dinamice.

Această diagramă completează în esență procesul OOAP pentru un anumit sistem software și dezvoltarea sa este de obicei ultima etapă a specificației modelului. Și mai multe tehnici speciale contribuie la aceasta (Scrum of scrums, echipe componente, participarea arhitectului în rolul de Product owner). Aceasta este dezvoltarea unui sistem real.

Și nu este nimic neobișnuit sau greșit în asta. Componentele sistemelor software, soiurile acestora. Toate diagramele discutate mai devreme reflectau aspectele conceptuale și logice ale construirii unui model de sistem. Pentru a explica diferența dintre reprezentările logice și cele fizice, este necesar să schiță generală luați în considerare procesul de dezvoltare a unui sistem software.

3.4.3. Aplicarea diagramelor de componente și de aspect

În acest caz, deja în textul programului se presupune organizarea codului programului, determinată de sintaxa limbajului de programare și presupunând împărțirea codului sursă în module separate. Și acest lucru este posibil numai dacă codul de program al sistemului este implementat sub formă de module executabile, biblioteci de clase și proceduri, interfețe grafice standard și fișiere de bază de date.

Diagrama componentelor și caracteristicilor construcției sale

Pentru a reprezenta entitățile fizice în limbajul UML, se folosește un termen special - componentă. Componenta este o parte existentă fizic a unui sistem care asigură implementarea claselor și relațiilor, precum și comportamentul funcțional al sistemului software care este modelat.

În plus, o componentă poate avea un stereotip text și valori etichetate, iar unele componente pot avea propria lor reprezentare grafică. Componenta poate fi cod executabil modul separat, fișiere batch sau fișiere care conțin scripturi interpretate.

Analiștii și arhitecții de sistem, precum și programatorii, sunt implicați în dezvoltarea diagramelor de componente. Componente și stereotipuri UML. Diagrama de implementare este concepută pentru a vizualiza elementele și componentele unui program care există doar în etapa de rulare. De asemenea, puteți defalca componente folosind diagrame de structură a componentelor. Aceasta sectiune este dedicată două diagrame simultan: componente și plasare, pentru care putem folosi o denumire generală - diagrame de implementare.

Toate diagramele discutate mai devreme reflectau aspectele conceptuale ale construirii unui model de sistem si legate de nivelul logic de prezentare. Particularitatea reprezentării logice este că operează cu concepte care nu au o întruchipare materială independentă. Cu alte cuvinte, diferitele elemente ale unei reprezentări logice, precum clasele, asociațiile, stările, mesajele, nu există material sau fizic. Ele reflectă doar înțelegerea noastră asupra structurii sistem fizic sau aspecte ale comportamentului ei.

Scopul principal al reprezentării logice este de a analiza relațiile structurale și funcționale dintre elementele modelului de sistem. Cu toate acestea, pentru a crea un sistem fizic specific, este necesar să implementăm cumva toate elementele reprezentării logice în entități materiale specifice. Pentru a descrie astfel de entități reale se urmărește un alt aspect al reprezentării modelului și anume reprezentarea fizică a modelului.

Pentru a explica diferența dintre reprezentările logice și cele fizice, să luăm în considerare în termeni generali procesul de dezvoltare a unui anumit sistem software. Reprezentarea sa logică inițială poate fi diagrame bloc algoritmi și proceduri, descrieri de interfețe și diagrame conceptuale ale bazelor de date. Totuși, pentru a implementa acest sistem, este necesară dezvoltarea codului sursă al programului într-un limbaj de programare (C++, Pascal, Basic/VBA, Java). În același timp, deja în textul programului se presupune că codul programului este organizat în așa fel încât să fie împărțit în module separate.

Cu toate acestea, codurile sursă ale programului nu reprezintă încă implementarea finală a proiectului, deși servesc ca un fragment al reprezentării sale fizice. Evident, un sistem software poate fi considerat implementat în cazul în care este capabil să îndeplinească funcțiile pentru scopul său. Și acest lucru este posibil numai dacă codul de program al sistemului este implementat sub formă de module executabile, biblioteci de clase și proceduri, interfețe grafice standard și fișiere de bază de date. Aceste componente sunt elementele necesare reprezentării fizice a sistemului.

Astfel, proiectarea completă a unui sistem software este un set de modele de reprezentări logice și fizice care trebuie să fie în concordanță între ele. UML folosește așa-numitele diagrame de implementare pentru a reprezenta fizic modelele de sistem, care includ două diagrame canonice separate: o diagramă de componente și o diagramă de implementare. Caracteristicile de construcție ale primului dintre ele sunt discutate în acest capitol, iar al doilea în următorul.

O diagramă de componente, spre deosebire de diagramele discutate anterior, descrie caracteristicile reprezentării fizice a sistemului. O diagramă de componente vă permite să definiți arhitectura sistemului în curs de dezvoltare prin stabilirea de dependențe între componente software, care poate fi cod sursă, binar și executabil. În multe medii de dezvoltare, un modul sau componentă corespunde unui fișier. Săgețile punctate care conectează modulele arată relații de interdependență similare cu cele care apar la compilarea codului sursă al programului. .Principalele elemente grafice ale unei diagrame de componente sunt componentele, interfețele și dependențele dintre ele.

O diagramă de componente este dezvoltată în următoarele scopuri:

Vizualizarea structurii generale a codului sursă al unui sistem software.
Specificațiile unei versiuni executabile a unui sistem software.
Asigurarea reutilizarii fragmentelor individuale de cod de program.
Reprezentări ale schemelor de baze de date conceptuale și fizice.

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 reprezentare logică la o implementare concretă a unui proiect sub formă de cod software. 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, tratându-le pe acestea din urmă ca clasificatori.

10.1. Componente

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 la desemnarea în general a elementelor reprezentării fizice a modelului. Pentru o reprezentare grafică a unei componente se poate folosi caracter special– un dreptunghi cu două dreptunghiuri mai mici introduse în stânga (Fig. 10.1). În interiorul dreptunghiului care îl încadrează este numele componentei și, eventual, câteva informații suplimentare. Aspectul acestui simbol poate varia ușor în funcție de natura informațiilor asociate cu componenta.

În metamodelul UML, o componentă este un copil al unui clasificator. Oferă organizare în cadrul unui pachet fizic elementelor sale de model asociate. Ca clasificator, o componentă poate avea și proprietăți proprii, cum ar fi atribute și operații.

Orez. 10.1. Reprezentarea grafică a unei componente în UML

Deci, în primul caz (Fig. 10.1, a) doar numele său este asociat cu componenta la nivel de instanță, iar în al doilea (Fig. 10.1, b) - în plus, numele pachetului și valoarea marcată.

Numele componentei

Numele componentei este supus reguli generale denumirea elementelor de model în limbajul UML și poate consta din orice număr de litere, cifre și unele semne de punctuație. O componentă individuală poate fi reprezentată la nivel de tip sau la nivel de instanță. Deși el imagine graficăîn ambele cazuri la fel, regulile de scriere a numelui componentei sunt ușor diferite. Dacă o componentă este reprezentată la nivel de tip, atunci numai numele tipului cu majuscule este scris ca nume.

Dacă componenta este reprezentată la nivel de instanță, atunci numele ei este scris<имя компонента ":" имя типаХ При этом вся строка имени подчеркивается.

Ca nume simple, se obișnuiește să se utilizeze numele fișierelor executabile (indicând extensia exe după punctul separator), numele bibliotecilor dinamice (extensia dll), numele paginilor Web (extensia html), numele fișierelor text (txt sau extensii doc) sau fișiere de ajutor (hip), numele fișierelor de baze de date (DB) sau numele fișierelor cu coduri sursă ale programelor (extensiile h, cpp pentru limbajul C++, extensia Java pentru limbajul Java), scripturi (pi, asp) , etc.

Deoarece implementarea specifică a reprezentării logice a modelului de sistem depinde de instrumentele software utilizate, denumirile componentelor vor fi determinate de caracteristicile de sintaxă ale limbajului de programare corespunzător.

În unele cazuri, la denumirea simplă a componentei pot fi adăugate informații despre numele pachetului inclus și versiunea specifică a implementării acestei componente (Fig. 10.1, b). Trebuie remarcat faptul că, în acest caz, numărul versiunii este scris ca valoare etichetată între acolade. În alte cazuri, un simbol de componentă poate fi împărțit în secțiuni pentru a indica în mod explicit numele interfețelor pe care le implementează. Această notație de componentă se numește extinsă și este discutată mai târziu în acest capitol.

Tipuri de componente

Deoarece o componentă, ca element al implementării fizice a unui model, reprezintă un modul de cod separat, uneori este comentată cu simboluri grafice suplimentare care ilustrează caracteristicile specifice implementării sale. Strict vorbind, aceste notații suplimentare de notație nu sunt specificate în UML. Cu toate acestea, utilizarea lor face diagrama componentelor mai ușor de înțeles, îmbunătățind semnificativ claritatea reprezentării fizice. Unele dintre aceste simboluri ale componentelor comune sunt prezentate mai jos (Figura 10.2).

Există trei tipuri de componente în UML.

În primul rând, componentele de implementare, care permit sistemului să-și îndeplinească direct funcțiile. Astfel de componente pot fi biblioteci de link-uri dinamice cu extensia dll (Fig. 10.2, a), pagini web în limbaj de marcare hipertext cu extensia html (Fig. 10.2, b) și fișiere de ajutor cu extensia Yp (Fig. 10.2, c) .
În al doilea rând, componentele sunt produse de lucru. De regulă, acestea sunt fișiere cu textele sursă ale programelor, de exemplu, cu extensiile h sau cpp pentru limbajul C++ (Fig. 10.2, d).
În al treilea rând, componentele de execuție, care reprezintă module executabile - fișiere cu extensia .exe. Ele sunt desemnate în mod obișnuit.

Orez. 10.2. Opțiuni pentru reprezentarea grafică a componentelor pe o diagramă de componente

Aceste elemente sunt uneori numite artefacte, subliniind continutul lor informativ complet, care depinde de tehnologia specifica pentru implementarea componentelor corespunzatoare. Mai mult, dezvoltatorii pot folosi propriile notații în acest scop, deoarece UML nu are o notație strictă pentru reprezentarea grafică a adnotărilor.

O altă modalitate de a specifica diferite tipuri de componente este de a specifica în mod explicit stereotipul componentei înaintea numelui său. UML definește următoarele stereotipuri pentru componente:

Bibliotecă – definește primul tip de componentă, care este reprezentată sub forma unei biblioteci dinamice sau statice.
Tabel – definește și primul tip de componentă, care este reprezentată sub forma unui tabel de bază de date.
Fișier – definește al doilea tip de componentă, care este reprezentat sub formă de fișiere cu codul sursă al programelor.
Document – definește al doilea tip de componentă, . care se prezintă sub forma unui document.
Executabil – definește al treilea tip de componentă care poate fi executată în nod.

10.2. Interfețe

Următorul element al diagramei componentelor sunt interfețele. Acestea din urmă au fost discutate de mai multe ori anterior, astfel încât acele caracteristici care sunt caracteristice prezentării pe diagramele componente vor fi notate aici. Să reamintim că în cazul general, interfața este reprezentată grafic printr-un cerc, care este legat de componentă printr-un segment de linie fără săgeți (Fig. 10.3, a). În acest caz, numele interfeței, care trebuie să înceapă cu litera „I”, este scris lângă cerc. Din punct de vedere semantic, o linie înseamnă o implementare a unei interfețe, iar prezența interfețelor pe o componentă înseamnă că această componentă implementează setul corespunzător de interfețe.

Orez. 10.3. Reprezentarea grafică a interfețelor pe o diagramă de componente

O altă modalitate de a reprezenta o interfață pe o diagramă de componente este reprezentarea acesteia ca un dreptunghi de clasă cu un stereotip „interfață” și posibile secțiuni de atribute și operații (Fig. 10.3, b). De obicei, această notație este folosită pentru a reprezenta structura internă a unei interfețe, care poate fi importantă pentru implementare.

Când se dezvoltă sisteme software, interfețele oferă nu numai compatibilitate între diferite versiuni, ci și capacitatea de a face modificări semnificative în anumite părți ale programului fără a modifica alte părți. Astfel, scopul interfețelor este mult mai larg decât specificarea interacțiunii cu utilizatorii (actorii) sistemului.

10.3. Dependente

În general, relația de dependență a fost discutată și mai devreme (vezi capitolul 5). Să reamintim că dependența nu este o asociere, ci servește pentru a reprezenta doar faptul existenței unei astfel de conexiuni, atunci când o modificare a unui element al modelului afectează sau duce la modificarea unui alt element al modelului. O relație de dependență într-o diagramă de componente este reprezentată de o linie punctată cu o săgeată care indică de la client (elementul dependent) la sursă (elementul independent).

Dependențele pot reflecta conexiunile dintre modulele programului în etapa de compilare și generare de cod obiect. Alternativ, dependența poate reflecta prezența în componenta independentă a definițiilor de clasă care sunt utilizate în componenta dependentă pentru a crea obiectele corespunzătoare. Când sunt aplicate unei diagrame de componente, dependențele pot lega componente și interfețele importate de acea componentă, precum și diferite tipuri de componente între ele.

În primul caz, trageți o săgeată de la componenta client la interfața importată (Fig. 10.4). Prezența unei astfel de săgeți înseamnă că componenta nu implementează interfața corespunzătoare, ci o folosește în timpul execuției sale. Mai mult, aceeași diagramă poate conține o altă componentă care implementează această interfață. Deci, de exemplu, fragmentul de diagramă de componente prezentat mai jos reprezintă informația că o componentă numită „main.exe” depinde de o interfață I Dialog importată, care la rândul său este implementată de o componentă numită „image.java”. Pentru a doua componentă, aceeași interfață este exportabilă.

Orez. 10.4. Fragment de diagramă componente cu relație de dependență

Rețineți că este imposibil să descrieți a doua componentă cu numele „image.java” sub forma unei note de variantă tocmai din cauza faptului că această componentă implementează interfața.

Un alt exemplu de relație de dependență într-o diagramă de componente este relația dintre diferitele tipuri de componente (Figura 10.5). Prezența unei astfel de dependențe înseamnă că efectuarea de modificări la codul sursă al programelor sau al bibliotecilor dinamice duce la modificări ale componentei în sine. În acest caz, natura modificărilor poate fi remarcată suplimentar.

Orez. 10.5. Reprezentarea grafică a relației de dependență dintre componente

În cele din urmă, o diagramă de componente poate reprezenta relații de dependență între componente și clasele pe care le implementează. Aceste informații sunt esențiale pentru a asigura coerența între reprezentările logice și fizice ale modelului de sistem. Desigur, modificările aduse structurii definițiilor de clasă pot schimba componenta. Mai jos este un fragment al unei dependențe de acest fel, când o componentă depinde de clasele corespunzătoare.

Orez. 10.6. Reprezentarea grafică a dependenței dintre o componentă și clase

Trebuie remarcat faptul că, în acest caz, diagrama componentelor nu implică faptul că clasele sunt implementate de această componentă. Dacă doriți să subliniați că o componentă implementează clase separate, atunci simbolul dreptunghi extins este folosit pentru a desemna componenta. În acest caz, dreptunghiul component este împărțit în două secțiuni printr-o linie orizontală. Secțiunea superioară este folosită pentru a înregistra numele componentei, iar secțiunea inferioară este utilizată pentru a indica informații suplimentare (Fig. 10.7).

Orez. 10.7. Reprezentare grafică a unei componente cu informații suplimentare despre clasele pe care le implementează

Alte elemente de notație grafică, cum ar fi clase (componentă la nivel de tip) sau obiecte (componentă la nivel de instanță), pot fi descrise într-un simbol de componentă. În acest caz, simbolul componentului este desenat pentru a găzdui aceste simboluri suplimentare. De exemplu, componenta de mai jos (Figura 10.8) este o instanță și implementează trei obiecte separate.

Orez. 10.8. Reprezentare grafică a unei componente la nivel de instanță care implementează obiecte individuale

Obiectele care se află într-o componentă de instanță separată sunt descrise ca imbricate în simbolul acelei componente. O astfel de imbricare înseamnă că execuția unei componente implică execuția obiectelor corespunzătoare. Cu alte cuvinte, existența unei componente în timpul execuției programului asigură existența, și eventual accesul, tuturor obiectelor imbricate în acesta. În ceea ce privește accesul la aceste obiecte, acesta poate fi specificat în continuare folosind cuantificatori de vizibilitate, similari cu vizibilitatea pachetelor. Conținutul vizibilității poate diferi pentru diferite tipuri de pachete.

Astfel, pentru componentele cu codul sursă al programului, vizibilitatea poate însemna posibilitatea de a face modificări la textele programului corespunzătoare cu recompilarea ulterioară a acestora. Pentru componentele cu cod de program executabil, vizibilitatea poate caracteriza capacitatea de a lansa componenta corespunzătoare pentru execuție sau operații de apel sau metode implementate în aceasta.

Elaborarea unei diagrame de componente presupune utilizarea informațiilor atât despre reprezentarea logică a modelului de sistem, cât și despre caracteristicile implementării sale fizice. Înainte de începerea dezvoltării, este necesar să se ia decizii cu privire la alegerea platformelor de calcul și a sistemelor de operare pe care ar trebui să fie implementat sistemul, precum și alegerea bazelor de date și a limbajelor de programare specifice.

După aceasta, puteți trece la structurarea generală a diagramei componentelor. În primul rând, este necesar să decideți din ce părți fizice (fișiere) va consta sistemul software. În această etapă, trebuie acordată atenție unei implementări a sistemului care să ofere nu numai posibilitatea reutilizarii codului prin descompunerea rațională a componentelor, ci și crearea de obiecte doar atunci când sunt necesare.

Ideea este că performanța globală a unui sistem software depinde în mod semnificativ de utilizarea rațională a resurselor de calcul. În acest scop, este necesară mutarea majorității descrierilor claselor, operațiunilor și metodelor acestora în biblioteci dinamice, lăsând în componentele executabile doar cele mai necesare fragmente de cod de program pentru inițializarea programului.

După structurarea generală a reprezentării fizice a sistemului, este necesară completarea modelului cu interfețe și scheme de baze de date. Când dezvoltați interfețe, ar trebui să acordați atenție coordonării (unării) diferitelor părți ale sistemului software. Includerea unei scheme de bază de date într-un model implică specificarea tabelelor individuale și stabilirea relațiilor de informații între tabele.

În cele din urmă, etapa finală a diagramării componentelor implică stabilirea și reprezentarea grafică a relațiilor dintre componente, precum și a relațiilor de implementare. Aceste relații ar trebui să ilustreze toate aspectele cele mai importante ale implementării fizice a sistemului, începând cu caracteristicile de compilare a codurilor sursă ale programelor și terminând cu execuția părților individuale ale programului în etapa de execuție a acestuia. În acest scop, puteți utiliza diferite tipuri de reprezentare grafică a componentelor.

Când dezvoltați o diagramă de componente, ar trebui să respectați principiile generale ale creării modelelor în limbajul UML. În special, în primul rând este necesar să se utilizeze componentele și stereotipurile deja disponibile în limbajul UML. Pentru majoritatea proiectelor tipice, acest set de elemente poate fi suficient pentru a reprezenta componentele și dependențele dintre ele.

Dacă proiectul conține unele elemente fizice care nu sunt descrise în limbajul UML, atunci ar trebui să utilizați mecanismul de extensie. În special, utilizați stereotipuri suplimentare pentru componentele individuale netipice sau valorile etichetate pentru a clarifica caracteristicile lor individuale.

În concluzie, trebuie remarcat faptul că o diagramă de componente este de obicei dezvoltată împreună cu o diagramă de implementare, care oferă informații despre amplasarea fizică a componentelor sistemului software în nodurile sale individuale. Caracteristicile construirii unei diagrame de implementare vor fi discutate în capitolul următor.

Note:

Nota 7

Exemplul discutat mai sus a folosit una dintre notațiile acceptate în unele limbaje de programare (de exemplu, Object Pascal) pentru a indica faptul că o metodă aparține unei anumite clase. În conformitate cu această notație, mai întâi este indicat numele clasei în care este definită metoda și apoi, despărțit printr-un punct, numele metodei în sine. Dacă o metodă este definită într-o subclasă, atunci trebuie specificat întregul lanț de clase, începând cu cea mai generală. În acest caz, o trăsătură caracteristică a unei metode este o pereche de paranteze care sunt folosite pentru a indica o listă de argumente sau parametri formali ai acestei metode.

Nota 72

Când sunt aplicate sistemelor de afaceri, componentele software trebuie înțelese într-un sens mai larg pentru a putea modela procesele de afaceri. În acest caz, unitățile organizatorice individuale (departamente, servicii) sau documentele care există efectiv în sistem sunt considerate componente.

Nota 73

Imaginea unei componente provine din desemnarea unui modul de program, care a fost folosit de ceva timp pentru a afișa caracteristicile de încapsulare a datelor și a procedurilor. Astfel, dreptunghiul mic de sus este asociat conceptual cu datele pe care le implementează această componentă (anterior era reprezentată în formă de oval). Dreptunghiul mic de jos este asociat cu operațiunile sau metodele implementate de componentă. În cazuri simple, datele și numele metodelor au fost scrise explicit în aceste dreptunghiuri mici, dar UML nu le specifică.

Nota 74

Deși convențiile de denumire a obiectelor UML necesită sublinierea numelui instanțelor individuale, sublinierea este adesea omisă pentru componente în literatură. În acest caz, scrierea numelui componentei cu o literă mică va caracteriza componenta la nivel de instanță.

Nota 75

Modul în care componentele individuale utilizează interfețele poate diferi. Prin urmare, există două moduri de a comunica între o interfață și o componentă. Dacă o componentă implementează o interfață, atunci se spune că interfața este exportabilă deoarece componenta o expune ca serviciu altor componente. Dacă o componentă folosește o interfață care este implementată de o altă componentă, atunci o astfel de interfață pentru prima componentă se numește importată. Particularitatea interfeței importate este că în diagrama componentelor această relație este descrisă folosind o dependență.