Tipuri de relații UML: Asociere, Dependență, Generalizare

Să le studiem în detaliu

Tipuri de relații ale diagramei de clasă UML

Asociație

Este un set de legături care conectează elemente ale modelului UML. De asemenea, definește câte obiecte iau parte la acea relație.

Dependenţă

Într-o relație de dependență, după cum sugerează și numele, două sau mai multe elemente sunt dependente unul de celălalt. În acest tip de relație, dacă facem o schimbare la un anumit element, atunci este posibil ca toate celelalte elemente să fie și ele afectate de schimbare.

Generalizare

Se mai numește și relație părinte-copil. În generalizare, un element este o specializare a unei alte componente generale. Poate fi înlocuit cu el. Este folosit mai ales pentru a reprezenta moștenirea.

Realizare

Într-o relație de realizare a UML, o entitate denotă o anumită responsabilitate care nu este implementată de la sine și cealaltă entitate care le implementează. Această relație se găsește mai ales în cazul interfețe.

Asociație

Este o relație structurală care reprezintă obiecte care pot fi conectate sau asociate cu un alt obiect din interiorul sistemului. Următoarele constrângeri pot fi aplicate relației de asociere.

• {implicit} – Constrângerile implicite specifică faptul că relația nu este manifestă; se bazează pe un concept.
• {ordonat} – Constrângerile ordonate specifică faptul că setul de obiecte de la un capăt al unei asocieri sunt într-un mod specific.
• {schimbabil} – Constrângerea modificabilă specifică faptul că conexiunea dintre diferite obiecte din sistem poate fi adăugată, eliminată și modificată conform cerințelor.
• {addOnly} – Precizează că noile conexiuni pot fi adăugate dintr-un obiect care se află la celălalt capăt o asociație.
• {îngheţat} – Specifică că atunci când se adaugă o legătură între două obiecte, atunci aceasta nu poate fi modificată în timp ce constrângerea înghețată este activă pe legătura dată sau o conexiune.

De asemenea, putem crea o clasă care are proprietăți de asociere; se numește ca o clasă de asociere.

Asociere reflexivă

Asocierea reflexivă este un subtip de relație de asociere în UML. Într-o asociere reflexivă, instanțele aceleiași clase pot fi legate între ele. Se spune că o instanță a unei clase este, de asemenea, un obiect.

Asocierea reflexivă afirmă că o legătură sau o conexiune poate fi prezentă în cadrul obiectelor aceleiași clase.

Să luăm în considerare un exemplu de fruct de clasă. Clasa de fructe are două exemple, cum ar fi mango și măr. Asocierea reflexivă afirmă că o legătură între mango și măr poate fi prezentă, deoarece acestea sunt cazuri din aceeași clasă, cum ar fi fructele.

Asociere dirijată

După cum sugerează și numele, asocierea direcționată este legată de direcția fluxului în cadrul claselor de asociere.

Într-o asociere dirijată, fluxul este direcționat. Asocierea de la o clasă la alta clasă curge într-o singură direcție.

Se notează folosind o linie continuă cu un vârf de săgeată.

Exemplu:

Puteți spune că există o relație de asociere dirijată între un server și un client. Un server poate procesa cererile unui client. Acest flux este unidirecțional, care circulă numai de la server la client. Prin urmare, o relație de asociere dirijată poate fi prezentă în cadrul serverelor și clienților unui sistem.

Dependenţă

Folosind o relație de dependență în UML, se poate relata modul în care diferitele lucruri dintr-un anumit sistem depind unele de altele. Dependența este folosită pentru a descrie relația dintre diferitele elemente din UML care depind unele de altele.

Stereotipurile

• "lega" – Bind este o constrângere care specifică faptul că sursa poate inițializa șablonul într-o locație țintă, folosind parametrii sau valorile furnizate.
• "deriva" – Reprezintă că locația unui obiect sursă poate fi calculată din obiectul țintă.
• „prieten” – Specifică faptul că sursa are vizibilitate unică în obiectul țintă.
• "instanță de" – Specifică faptul că instanța unui clasificator țintă este obiectul sursă.
• „instancia” – Specifică faptul că obiectul sursă este capabil să creeze instanțe ale unui obiect țintă.
• "rafina" – Specifică faptul că obiectul sursă are abs excepționaletracțintă decât cea a obiectului țintă.
• "utilizare" – Este folosit când pachetele sunt create în UML. Stereotipul de utilizare descrie faptul că elementele unui pachet sursă pot fi prezente și în interiorul pachetului țintă. Acesta descrie faptul că pachetul sursă folosește unele elemente ale unui pachet țintă.
• "substitui" – precizează că clientul poate fi înlocuit cu furnizorul în timpul execuției.
• "acces" – Specifică faptul că pachetul sursă accesează elementele pachetului țintă care se mai numește și fuziune privată.
• "Import" – Specifică faptul că ținta poate importa elementul unui pachet sursă așa cum sunt definite în interiorul țintă care se mai numește și fuziune publică.
• "permite" – precizează că elementul sursă are acces la elementul furnizor indiferent de vizibilitatea declarată a furnizorului.
• "extinde" – Vă ajută să specificați că ținta poate extinde comportamentul elementului sursă.
• "include" – Vă permite să specificați elementul sursă care poate fi inclus comportamentul altui element într-o locație specificată. (la fel ca un apel de funcție în c/c++)
• "deveni" – Specifică faptul că ținta este similară cu sursa cu valori și roluri diferite.
• "apel" – Specifică că sursa poate invoca o metodă obiect țintă.
• "copie" – Specifică faptul că obiectul țintă este independent, copie a unui obiect sursă.
• "parametru" – furnizorul este un parametru al operațiunilor clientului.
• "trimite" – clientul este o operațiune care trimite furnizorului o țintă nespecificată.

Stereotipuri printre mașinile de stat

• "trimite" – Specifică faptul că operația sursă trimite evenimentul țintă.

Generalizare

Este o relație între o entitate generală și o entitate unică care este prezentă în interiorul sistemului.

Într-o relație de generalizare, conceptul orientat pe obiecte numit moștenire poate fi implementat. Între două obiecte există o relație de generalizare, numite și entități sau lucruri. Într-o relație de generalizare, o entitate este părinte, iar alta se spune că este copil. Aceste entități pot fi reprezentate folosind moștenirea.

În moștenire, un copil al oricărui părinte poate accesa, actualiza sau moșteni funcționalitatea așa cum este specificată în obiectul părinte. Un obiect copil își poate adăuga funcționalitatea și poate moșteni structura și comportamentul unui obiect părinte.

Acest tip de relație este cunoscut în mod colectiv ca relație de generalizare.

Stereotipurile și constrângerile lor

• „implementare” – Acest stereotip este folosit pentru a reprezenta că entitatea copil este implementată de entitatea părinte prin moștenirea structurii și comportamentului unui obiect părinte fără a încălca regulile. Notă: Acest stereotip este utilizat pe scară largă într-o singură moștenire.

Relația de generalizare conține constrângeri precum complet, incomplet pentru a verifica dacă toate entitățile copil sunt incluse sau nu în relație.

Realizare

Într-o relație de realizare a UML, o entitate denotă o anumită responsabilitate care nu este implementată de la sine și cealaltă entitate care le implementează. Această relație se găsește mai ales în cazul interfețe.

Realizarea poate fi reprezentată în două moduri:

• Folosind un formă canonică
• Folosind un formă elidizată

În diagrama de mai sus, regulile de afaceri ale contului realizează interfața IRuleAgent.

Tipuri de realizare

1. Formă canonică: Într-o relație de realizare UML, forma canonică este utilizată pentru a realiza interfețe în întregul sistem. Se utilizează un stereotip de interfață pentru a crea o interfață, iar relația de realizare este utilizată pentru a realiza interfața respectivă. Într-o formă canonică, relația de realizare este notată cu linia punctată direcționată cu un vârf de săgeată deschis de dimensiuni considerabile. În diagrama de mai sus, interfața Iruleagent este realizată folosind un obiect numit Account Business Rules.
2. Formă omisă: Realizare în Diagrama de clasă UML poate fi reprezentată și folosind o formă elidată. Într-o formă elidată, interfața este reprezentată printr-un cerc, numit și notație lollipop. Această interfață, atunci când este realizată folosind orice element prezent în sistem, creează o structură elidată. În diagrama de mai sus, interfața Iruleagent este reprezentată printr-o formă elidată, realizată de fișierul acctrule.dll.

Compoziție

Nu este o relație UML standard, dar este încă folosită în diverse aplicații.

Agregarea compusă este un subtip de relație de agregare cu caracteristici precum:

• este o asociere bidirecțională între obiecte.
• Este o relație întreg/parte.
• Dacă un compozit este șters, toate celelalte părți asociate cu acesta sunt șterse.

Agregarea compozită este descrisă ca o asociere binară decorată cu un diamant negru umplut la capătul agregat (întreg).

Un folder este o structură care deține n număr de fișiere în el. Un folder este folosit pentru a stoca fișierele din interiorul acestuia. Fiecare folder poate fi asociat cu orice număr de fișiere. Într-un sistem informatic, fiecare fișier face parte din cel puțin un folder din sistemul de organizare a fișierelor. Același fișier poate face și parte dintr-un alt folder, dar nu este obligatoriu. Ori de câte ori un fișier este eliminat din folder, folderul rămâne neafectat, în timp ce datele legate de acel fișier sunt distruse. Dacă o operațiune de ștergere este executată pe folder, atunci aceasta afectează și toate fișierele care sunt prezente în folder. Toate fișierele asociate folderului sunt distruse automat odată ce folderul este eliminat din sistem.

Acest tip de relație în UML este cunoscut prin relație de agregare compusă.

agregare

An agregare este un subtip al unei relații de asociere în UML. Agregarea și compoziția sunt ambele tipuri de relații de asociere în UML. O relație de agregare poate fi descrisă în cuvinte simple ca „un obiect al unei clase poate deține sau accesa obiectele altei clase”.

Într-o relație de agregare, obiectul dependent rămâne în sfera unei relații chiar și atunci când obiectul sursă este distrus.

Să luăm în considerare un exemplu de mașină și roată. O mașină are nevoie de o roată pentru a funcționa corect, dar o roată nu are întotdeauna nevoie de o mașină. Poate fi folosit și cu bicicleta, bicicleta sau orice alte vehicule, dar nu cu o anumită mașină. Aici, obiectul roată are sens chiar și fără obiectul mașină. Un astfel de tip de relație se numește relație de agregare.

Întrebări frecvente