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)