Sintaxa şi semantica

limbajului de modelare UML

 Alfabet şi cuvinte
Alfabetul defineşte cele mai mici părţi ale limbajului; UML este alcătuit din
simboluri (dreptunghiuri, linii şi alte elemente grafice) şi din şiruri de caractere.
Cuvântul este cea mai mică unitate semantică de limbaj. Un cuvânt este un
grup format din elementele alfabetului, care are un înţeles.
În UML, cuvintele sunt grupate în două categorii mari:
• entităţi sau concepte – desemnează o serie de abstracţii şi sunt
reprezentate prin simboluri etichetate cu nume;
• relaţiile dintre entităţi – desemnează tipurile de legături care pot exista între
entităţi. Ele sunt reprezentate prin linii de legătură între simboluri şi au un
nume.
Cuvintele limbajului alcătuiesc vocabularul limbajului.
 Propoziţii şi paragrafe

Propoziţiile UML sunt fragmente de diagrame sau diagrame simple .

• O companie de asigurări are contract de asigurare cu o persoană.

• O persoană are un contract de asigurare cu o companie de asigurare.

Paragrafele UML se numesc diagrame.

Sintaxa limbajului UML implică diagrame.

!
Semantica limbajului UML se bazează pe paradigma orientării pe obiecte.
În UML, diagramele fac parte din două categorii:

• Diagrame statice sau structurale - descriu structura, responsabilităţile

sistemului informatic, componentele executabile ale sistemului, locaţiile
fizice de execuţie şi nodurile de stocare a datelor. Din această categorie,
fac parte diagrame ale claselor, ale obiectelor, ale cazurilor de utilizare,
ale componentelor şi diagrame de exploatare.

• Diagrame dinamice sau comportamentale – descriu comportamentul

şi interacţiunile dintre diverse entităţi ale sistemului informatic. Din
această categorie, fac parte diagramele de secvenţă, de colaborare, de
stare şi de activitate.
 A) Modelare structurală (modelare statică)

• Se referă la vizualizarea, la specificarea, la construirea şi la documentarea

aspectelor statice ale unui sistem, adică la relaţiile invariante dintre componentele
unui sistem. Din punct de vedere al modelării sistemelor orientate pe obiecte din
perspectiva UML, aspectele statice sunt: clasele şi relaţiile dintre clase,
interfeţele, topologia hard necesară execuţiei aplicaţiei.

A1) Diagrama claselor (Class Diagram)

• Descrie structura unui sistem în general. În componenţa ei intră clase,
stereotipuri şi relaţiile dintre acestea. Acest tip de diagrame este cel mai des
întâlnit în modelarea sistemelor orientate pe obiecte.

A2) Diagrama obiectelor (Object Diagram)

• Descrie structura unui sistem la un anumit moment. Acest tip de diagramă este
o variantă a diagramei claselor, care, în locul unei clase, prezintă mai multe
instanţe ale ei şi este formată din obiecte şi relaţiile (legăturile) dintre ele. Este
folosită în exemplificarea unei diagrame a claselor de complexitate mare,
permiţând vizualizări statice ale instanţelor actuale şi ale relaţiilor.
A3) Diagrama cazurilor de utilizare (Use Case Diagram)
• Descrie funcţionalitatea unui sistem.

• Prezintă actorii externi, cazurile de utilizare identificate numai din punct de

vedere al actorilor (comportamentul sistemului, aşa cum este perceput de
utilizatorii lui), nu şi din interior, precum şi relaţiile dintre actori şi cazurile de
utilizare.

• Un actor poate fi orice sau oricine interacţionează cu sistemul (trimite sau

recepţionează mesaje de la sistem sau schimbă informaţii cu acesta).

• Actorul are un rol în cadrul unui sistem, nu este un utilizator individual al

acestuia, şi din acest motiv, el este o entitate (o clasă), nu o instanţă. Un caz de
utilizare este iniţiat mereu de un actor şi furnizează o valoare actorului.

• Diagramele cazurilor de utilizare reflectă modul static de vizualizare a cazurilor

de utilizare asupra sistemului (diferite tipuri de relaţii între cazurile de utilizare), dar
şi modul de organizare şi de modelare a comportamentului unui sistem.
A4) Diagrama componentelor (Component Diagram)
• O diagramă a componentelor, cunoscută şi sub numele de diagramă de
implementare, descrie structura fizică a codului în termenii componentelor de
cod şi relaţiile dintre acestea.

• Acest tip de diagramă realizează o mapare de la view-ul static (logic) la view-ul

componentelor. O componentă poate să conţină un cod sursă sau să fie sub
formă binară sau executabilă. O componentă se mapează, de obicei, pe una sau
mai multe clase, interfeţe sau colaborări; din această cauză, diagrama
componentelor are legătură cu diagrama claselor.
• Diagramele de componente reflectă vederea statică de implementare asupra
sistemului.

5) Diagrama de desfăţurare (Deployment Diagram)

• Diagrama de desfăşurare indică arhitectura fizică pe care este implementat
sistemul, calculatoarele, device-urile (noduri ale sistemului) şi conexiunile dintre
ele.
 B) Modelare dinamică (modelare comportamentală)
B1) Diagrama de interacţiune (Interaction Diagram)
• Descrie interacţiunile în timp între obiecte, relaţiile şi mesajele care circulă
între acestea. Diagramele de interacţiune reflectă vederea dinamică de design şi
de proces.
• Pot fi: a) Diagrama de secvenţă
b) Diagrama de colaborare
a) Diagrama de secvenţă (Sequence Diagram)
- Prezintă colaborarea dinamică dintre un număr de obiecte, punând accentul pe
secvenţe de mesaje trimise între acestea pe măsura scurgerii timpului.
- Au două axe: timpul, pe axa verticală, şi setul de obiecte, pe axa orizontală.
a) Diagrama de colaborare (Collaboration Diagram)
- Este o diagramă de interacţiune, dar, pe lângă interacţiunea dintre obiecte
(schimbul de mesaje), prezintă şi obiectele şi legăturile dintre ele. Când trebuie să
decidem ce tip de diagramă trebuie folosit pentru a ilustra o interacţiune, avem în
vedere aspectul cel mai important de evidenţiat.

Obs. Se vor folosi diagramele de secvenţă dacă cel mai important aspect este
timpul sau secvenţa de mesaje şi vom folosi diagramele de colaborare când
trebuie evidenţiat contextul.
 B2) Diagrama de stare (State Diagram)
• Descrie ciclul de viaţă al unui element (al obiectelor, al subsistemelor şi al
sistemelor), prin specificarea stărilor în care se găseşte un element şi a
evenimentelor (mesaje, erori, condiţii care devin adevărate) care îi modifică starea
(tranziţie).
Obs. Este indicat să se construiască diagrame de stare numai pentru clasele din
sistem care au un număr de stări bine definit şi în care comportamentul clasei
este influenţat de acestea. Aceste diagrame intră în modurile de vizualizare design
şi de proces asupra sistemului.

B3) Diagrama de activitate (Activity Diagram)

• Prezintă activităţile şi responsabilităţile elementelor sistemului.
• Diagramele de activitate au ca elemente constitutive stări de acţiune (Action
States) şi mesaje care vor fi trimise sau recepţionate ca parte a acţiunii realizate.
• Reflectă vederea dinamică de design şi de proces şi sunt utilizate pentru
modelarea funcţiilor sistemului.
 Secţiuni (Views)
Secţiunile UML sunt perspectivele arhitecturale sau modurile de vizualizare
(arhitectural views). Din punct de vedere gramatical, ele sunt formate din mai
multe paragrafe.

Obs. Un model UML descrie ce trebuie să facă un sistem, nu cum să se

implementeze sistemul.

Secţiunile UML sau modurile de vizualizare sunt grupuri de diagrame care se

adresează unei anumite mulţimi de concepte (entităţi).

Modelul capturează cunoştinţe şi le comunică sub formă de mod de vizualizare

sau, pe scurt, “view” (arhitectural views).

Fiecare view focalizează atenţia echipei de realizatori asupra unui anumit tip de
probleme şi de aspecte privind subiectul tratat şi se adresează unei categorii
speciale de firme sau de instituţii.

Un sistem poate fi descris luând în considerare următoarele aspecte:

• funcţional - este descrisă structura statică şi comportamentul dinamic al sistemului;
• non-funcţional - necesarul de timp pentru dezvoltarea sistemului;
• organizatoric - organizarea lucrului, maparea modulelor de cod.
Elementele care construiesc un view se numesc elemente de vizualizare (view
elements).

Fiecare view este descris folosind un număr de diagrame care conţin informaţii
referitoare la un anumit aspect particular al sistemului.

Aceste view-uri se acoperă unele pe altele, deci este posibil ca o anumită

diagramă să facă parte din mai multe view-uri.
V1) Modul de vizualizare cazuri de utilizare
(The use-case or user view)

• Acest view surprinde funcţionalitatea sistemului, aşa cum este ea percepută de

actorii externi care interacţionează cu sistemul, precum şi de utilizatorii acestuia,
de diferiţi membri ai echipei realizatoare sau de alte sisteme.

• În componenţa lui intră diagramele cazurilor de utilizare pentru descrierea

statică a aspectului funcţional şi ocazional.

• Se pot folosi şi diagrame de activitate pentru a încapsula latura dinamică a

funcţionalităţii.

• Cei interesaţi de această perspectivă sunt clienţii, designerii, dezvoltatorii şi

cei care vor testa şi vor valida sistemul realizat.
V2) Modul de vizualizare structural sau logic sau design
(The structural or logic or design view)

• Se referă la cerinţele funcţionale ale acestuia, adică prezintă serviciile

asigurate de sistem utilizatorilor săi.

• Vizualizarea logică tratează din interior sistemul şi descrie atât structura internă
a acestuia, formată din clase, obiecte şi relaţii, cât şi colaborările care apar în
urma schimbului de mesaje între obiecte, pentru a realiza funcţionalitatea dorită.

• Structura statică este descrisă de diagramele de clasă şi de obiecte, care

includ elementele şi relaţiile care alcătuiesc sistemul.

• Pentru modelarea dinamicii sistemului, se vor folosi diagrame de stare, de

secvenţă, de colaborare sau de activitate.

• Cei care sunt interesaţi de acest tip de vizualizare a sistemului sunt designerii şi
dezvoltatorii.
V3) Modul de vizualizare componente sistem sau implementare
(The implementation or component view)
• View-ul componentelor se concentrează pe descrierea componentelor care
implementează sistemul, dependenţele care există între ele, resursele alocate
acestora, precum şi rezolvarea unor probleme legate de reutilizarea, portabilitatea
codului, informaţii administrative, cum ar fi un desfăşurător al muncii de
dezvoltare.
• Este folosit de dezvoltatorii sistemului, iar în componenţa sa intră diagramele de
componente, care descriu cum este implementat sistemul.

V4) Modul de vizualizare comportamental sau dinamic sau proces sau

concurenţă (The behavioral or dinamic or process or concurent view)
• Acest mod de vizualizare ia în considerare cerinţele de performanţă, de
fiabilitate, de utilitate, etc.
• Pentru descrierea comportamentului şi a dinamicii sistemului, se folosesc
diagramele de stare, de secvenţă, de colaborare şi de activitate.
• În reprezentarea acestui mod de vizualizare a sistemului, se folosesc şi
diagramele de implementare (ale componentelor).
• Cei interesaţi de o astfel de vizualizare a sistemului sunt dezvoltatorii şi
interogatorii de sistem.
V5) Modul de vizualizare desfăşurare sau mediu
(The deployment or environment view)
• În acest mod de vizualizare sunt surprinse desfăşurarea fizică a sistemului, ce
calculatoare şi ce tipuri de device-uri (noduri) vor fi folosite pentru implementarea
sistemului, cum sunt acestea conectate, precum şi ce componente (procese) se
vor executa în fiecare nod.
• Acest tip de vizualizare este reprezentat cu ajutorul unor diagrame de
desfăşurare, care indică modul de implementare a sistemului. În acest sens, ele
poartă etichete care specifică repartizarea pe tipuri de activitate şi informaţii
despre procesele executate în noduri.

• De acest tip de vizualizare sunt interesaţi dezvoltatorii, interogatorii de

sistem, precum şi cei care realizează testarea sistemului.
 Documente (Modele)

Un document este format dintr-un număr de secţiuni care descriu un subiect

comun şi pot fi cărţi, articole etc.

Documentele UML sunt modele. Un model este o reprezentare a unui sistem.

View-urile (secţiunile) sunt grupate formând modelul (documentul) arhitectural al
sistemului studiat.

Pentru paradigma de modelare UML, cel mai adecvat este modelul de dezvoltare
a sistemului dirijat de cazurile de utilizare, centrat pe arhitectură, iar abordarea
este iterativă sau cascadă.
 Pachete (Packages)

Un pachet reprezintă un mecanism de grupare a elementelor de modelare.

În UML, un pachet defineşte un mecanism de organizare a elementelor în grupuri

legate semantic. Rezultă că un element de modelare nu poate fi prins în mai
multe pachete, dar un pachet poate importa elemente de modelare din alte
pachete, iar după import le consideră ca şi când ar fi proprietatea lui.

Putem stabili relaţii între pachete, dar numai între tipuri, nu şi între instanţe
(pachetele nu au semantică definită de instanţe).

Un pachet poate să aibă vizibilitate, ca şi clasele, prin care se precizează

modalitatea prin care alte pachete pot să-i acceseze conţinutul.

Un pachet poate să aibă o interfaţă care îi redă comportamentul.

 Note (Notes)

O notă cuprinde ipotezele şi deciziile aplicate în timpul analizei şi al proiectării.

Notele sunt corespondentul comentariilor din limbajele de programare.

Notele pot conţine orice informaţie, inclusiv fragmente de cod sau referiri la alte
documente, şi se pot folosi în orice tip de diagrame. Ele se reprezintă printr-un
dreptunghi cu colţul dreapta sus îndoit, în interiorul căruia se află informaţia dorită.

Nota este ataşată unui element dintr-o diagramă printr-o linie punctată.
O notǎ poate să nu fie conectată, dacă aceasta se referă la întreaga diagramă.
 Stereotipuri (Stereotypes)

Stereotipul este un concept introdus în UML, care permite extinderea elementelor

de bază pentru a crea noi elemente.

Un stereotip reprezintă un înţeles specific asociat unui element. El se reprezintă

printr-un cuvânt între paranteze unghiulare duble (“<< >>”), scris deasupra sau
dedesubtul numelui elementului asociat.

Obs. Un stereotip transformă un element în altul cu un înţeles nou.

Exemplu. Dacă se ataşează stereotipul <<table>> clasei Examene, acesta va

reprezenta o bază de date tabelară.
 Proprietăţi

Proprietăţile sunt elemente de extindere UML, care lărgesc proprietăţile şi

semantica unui element UML.
Ele se reprezintă printr-o listă de şiruri de caractere între acolade ({ }), scrise
deasupra sau dedesubtul elementului UML.
Şirurile de caractere care reprezintă proprietăţile pot fi de două forme:
• valoare etichetată (tagged value) - se exprimă prin perechea "string = valoare"
şi reprezintă caracteristicile unui element şi valorile sale;
• constrângeri (constraints) - se exprimă în OCL (Object Constraint Language)
şi reprezintă condiţiile pe care trebuie să le satisfacă elementul.

Exemplu. valorile etichetate ale clasei EXAMENE sunt versiunea şi autorul, iar
constrângerea este perioada de examene.
Reprezentarea grafică a elementelor de modelare
Reprezentarea grafică a elementelor de modelare (continuare)
Reprezentarea grafică a elementelor de modelare (continuare)