Diagrama de clase descrie din punct de vedere structural sistemului evidenţiind clasele acestuia, atributele, metodele şi relaţiile dintre clase.

Principalele elemente ale unei diagrame de clase sunt:

• Clasa – este reprezentată sub forma unui dreptunghi în interiorul căruia este notat numele clasei. Opţional în interiorul unei clase pot fi reprezentate atributele şi metodele acesteia (doar semnătura).
• Interfaţa – este reprezentată sub forma unui dreptunghi în interiorul căruia este notat numele interfeţei. Ca şi alternativă o interfaţă mai poate fi reprezentată în mod simplificat sub forma unui cerc în dreptul căruia este trecut numele interfeţei. Interfaţa poate fi considerată un caz particular de clasă.
• Relaţia - este reprezentată sub forma unei drepte orientate sau nu ce leagă două clase. O relaţie de asociere dintre două clase semnifică o relaţie de colaborare sau de înrudire între clasele conectate. Tipurile de relaţii posibile între două clase sunt: asociere, agregare, compoziţie, implementare şi moştenire.

Diagramele de clase pot fi folosite în diferite stadii ale procesului de dezvoltare a aplicaţiei pentru: definirea modelului conceptual şi prezentarea entităţilor principale ale sistemului, definirea arhitecturii sistemului la nivel detaliat.

Atributele sunt reprezentate în interiorul claselor din care fac parte şi sunt scrise sub forma: specificator_de_acces nume: tip_returnat. Numele atributelor încep prin convenţie cu literă mică.

Metodele pot fi reprezentate de asemenea în interiorul claselor din care fac parte şi sunt scrise sub forma: specificator_de_acces nume_metoda (tip1:parametru1, tip2:parametru2, …, tipn parametrun): tip returnat. Numele metodelor încep prin convenţie cu literă mică.

Tipurile posibile de specificatori de acces sunt:

• Public – şi este reprezentat în cadrul diagramelor prin caracterul „+”.
• Private – şi este reprezentat în cadrul diagramelor prin caracterul „-”.
• Protected – şi este reprezentat prin caracterul „#”.
• Acces de pachet – şi este reprezentat în cadrul diagramelor prin caracterul „~”.

O diagramă de clase poate fi desenată cu diferite nivele de granularitate a detaliilor, mergând de la varianta cea mai schematică în care sunt reprezentate doar numele claselor (fără detalii referitoare la conţinutul acestora) până la varianta cea mai detaliată în care sunt reprezentate toate atributele şi metodele indiferent de nivelul de acces. Una dintre cele mai utilizate variante este cea în care sunt reprezentate doar metodele şi \ sau atributele publice ale clasei.

Asocierea este cel mai slab tip de interconectare dintre două clase. Între două clase se defineşte o astfel de relaţie atunci când între acestea există un flux de date sau de mesaje.

O asociere poate fi bidirecţională (caz în care asocierea este reprezentată cu o dreaptă simplă) sau unidirecţională (caz în care asocierea este reprezentată printr-o dreaptă orientată. O asociere bidirecţională are un nume, fiecare capăt al dreptei ce o reprezintă având ataşate următoarele elemente:

• Un indicator de multiplicitate – ce defineşte câte obiecte de tipul clasei din capătul legăturii de asociere pot fi asociate cu un obiect din capătul celălalt al legăturii de asociere.
• Un rol – ce defineşte numele sub care obiectele de la capătul curent al asocierii sunt cunoscute în capătul celălalt al asocierii.

Pentru definirea indicatorului de multiplicitate UML pune la dispoziţie următoarele notaţii standard:

• * - oricate obiecte
• 1…* - cel putin un obiect sau mai multe
• 1 - un obiect
• n - exact n obiecte
• a…b - cel putin a obiecte si maxim b obiecte

Diagrama de mai sus poate fi interpretată astfel: Clasa Phone are cunoştinţă de existenţa clasei Button şi obiectele de tip Button vor juca rolul de phoneButtons în cadrul clasei Phone. Atunci când clasa Phone va fi creată aceasta va avea acces la un număr nedefinit de butoane (zero sau oricâte). Clasa Button are cunoştinţă de existenţa clasei Phone şi aceasta va juca rolul phone în cadrul clasei Button. Când un obiect de tip Button va fi creat acesta va avea acces la exact un obiect de tip Phone.

Observatie: O greşeală comună este aceea de ataşare a operatorului de multiplicitate la capătul greşit al legăturii de asociere. Operatorul de multiplicitate trebuie ataşat în dreptul clasei al cărui număr de obiecte sunt constrânse.

În cazul asocierii unidirecţionale doar una dintre clase are cunoştinţă de existenţa celeilalte clase. Acest tip de asociere este reprezentat printr-o dreaptă orientată având capătul săgeţii orientat spre clasa cunoscută. În figura de mai jos este exemplificată o asociere unidirecţională.

Dacă existenţa unei asociaţii între două clase necesită construirea unui alt obiect care să memoreze informaţii suplimentare legate de acea asocierea atunci aceasta se poate reprezenta printr-o clasă asociată conform figurii de mai sus.

Diagrama de mai sus poate fi interpretată astfel: atunci când sunt construite obiectele Controler şi TrafficLight şi va exista o asociere între ele, va fi construit şi un obiect de tip ControlAlgorithm.

Un alt caz de asociere între clase este cel care defineşte relaţia întreg – parte componentă. Acest tip de legătură defineşte o relaţie mai strânsă între părţile implicate. Pentru a modela faptul că un întreg este compus din una sau mai multe componente limbajul UML pune le dispoziţie asocierile de tip agregare simplă şi asocierile de tip agregare de compoziţie.

Diagrama de mai sus poate fi interpretată astfel: Obiectele de tip Whell şi Engine sunt părţi componentă a obiectului de tip Car. Ciclul de viaţă al obiectelor de tip parte nu este în mod obligatoriu acelaşi cu ciclul de viaţă al obiectului de tip Car (un obiect de tip Engine poate fi creat înaintea obiectului de tip Car şi poate fi ataşat ulterior la acesta, mai mult decât atât, distrugerea obiectului de tip Car nu înseamnă în mod implicit ca va determina şi distrugerea obiectului de tip Engine ).

Agregarea de compoziţie denotă tot o relaţie de tip întreg-parte dar care este mult mai strânsă. Ciclul de viaţă al părţilor este strâns legat de ciclul de viaţă al întregului, mai mult de cât atât, întregul este responsabil pentru crearea obiectelor de tip parte. Distrugerea întregului determină şi distrugerea părţilor. În figura de mai jos este exemplificată o diagramă de compoziţie.

Relaţia de moştenire este reprezentată în cadrul UML printr-o săgeată orientată către clasa de bază (clasa moştenită).

Pentru a reprezenta relaţia de implementare a unei interfeţe de către o clasă limbajul UML pune la dispoziţie două notaţii ce sunt prezentate în figura de mai jos.

Atat in diagrama din stanga cat si in diagrama din dreapta este exemplificata relatia de implementare a unei interfete.

In diagrama din stanga interfata este reprezentata schematic (doar numele clasei).

In diagrama din dreapta interfata este reprezentata in mod similar cu o clasa obisnuita avand incluse metodele declarate de interfata.

• Înainte de a începe construirea efectivă a diagramelor trebuiesc identificate principalele clase ale sistemului, responsabilităţile acestora precum şi colaboratorii.
• Numele claselor trebuie să fie cât mai explicite şi să reflecte cât mai aproape rolul clasei în cadrul sistemului.
• Construirea diagramelor de clase pentru un sistem este un proces iterativ şi acestea pot fi modificate pe măsură ce sistemul este construit.
• Trebuie folosite convenţiile de nume pentru clase, atribute şi metode corespunzătoare limbajului în care sistemul va fi implementat.