Sintaxa i semantica limbajului de modelare UML

Alfabet i cuvinte
Alfabetul definete cele mai mici pri ale limbajului; UML este alctuit din simboluri (dreptunghiuri, linii i alte elemente grafice) i din iruri de caractere. Cuvntul este cea mai mic unitate semantic de limbaj. Un cuvnt este un grup format din elementele alfabetului, care are un neles. n UML, cuvintele sunt grupate n dou categorii mari: entiti sau concepte desemneaz o serie de abstracii i sunt reprezentate prin simboluri etichetate cu nume; relaiile dintre entiti desemneaz tipurile de legturi care pot exista ntre entiti. Ele sunt reprezentate prin linii de legtur ntre simboluri i au un nume. Cuvintele limbajului alctuiesc vocabularul limbajului.

Propoziii i paragrafe
Propoziiile UML sunt fragmente de diagrame sau diagrame simple .

O companie de asigurri 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 orientrii pe obiecte.

n UML, diagramele fac parte din dou categorii: Diagrame statice sau structurale - descriu structura, responsabilitile

sistemului informatic, componentele executabile ale sistemului, locaiile fizice de execuie 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 interaciunile dintre diverse entiti 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 relaiile invariante dintre componentele unui sistem. Din punct de vedere al modelrii sistemelor orientate pe obiecte din perspectiva UML, aspectele statice sunt: clasele i relaiile dintre clase, interfeele, topologia hard necesar execuiei aplicaiei.

A1) Diagrama claselor (Class Diagram) Descrie structura unui sistem n general. n componena ei intr clase, stereotipuri i relaiile dintre acestea. Acest tip de diagrame este cel mai des ntlnit 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 instane ale ei i este format din obiecte i relaiile (legturile) dintre ele. Este folosit n exemplificarea unei diagrame a claselor de complexitate mare, permind vizualizri statice ale instanelor actuale i ale relaiilor.

A3) Diagrama cazurilor de utilizare (Use Case Diagram) Descrie funcionalitatea unui sistem. Prezint actorii externi, cazurile de utilizare identificate numai din punct de vedere al actorilor (comportamentul sistemului, aa cum este perceput de utilizatorii lui), nu i din interior, precum i relaiile dintre actori i cazurile de utilizare. Un actor poate fi orice sau oricine interacioneaz cu sistemul (trimite sau recepioneaz mesaje de la sistem sau schimb informaii 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 iniiat 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 relaii 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 relaiile dintre acestea. Acest tip de diagram realizeaz o mapare de la view-ul static (logic) la view-ul componentelor. O component poate s conin un cod surs sau s fie sub form binar sau executabil. O component se mapeaz, de obicei, pe una sau mai multe clase, interfee sau colaborri; din aceast cauz, diagrama componentelor are legtur cu diagrama claselor. Diagramele de componente reflect vederea static de implementare asupra sistemului. 5) Diagrama de desfurare (Deployment Diagram) Diagrama de desfurare 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 interaciune (Interaction Diagram) Descrie interaciunile n timp ntre obiecte, relaiile i mesajele care circul ntre acestea. Diagramele de interaciune 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 numr de obiecte, punnd accentul pe secvene de mesaje trimise ntre acestea pe msura 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 interaciune, dar, pe lng interaciunea dintre obiecte (schimbul de mesaje), prezint i obiectele i legturile dintre ele. Cnd trebuie s decidem ce tip de diagram trebuie folosit pentru a ilustra o interaciune, avem n vedere aspectul cel mai important de evideniat. Obs. Se vor folosi diagramele de secven dac cel mai important aspect este timpul sau secvena de mesaje i vom folosi diagramele de colaborare cnd trebuie evideniat contextul.

B2) Diagrama de stare (State Diagram) Descrie ciclul de via al unui element (al obiectelor, al subsistemelor i al sistemelor), prin specificarea strilor n care se gsete un element i a evenimentelor (mesaje, erori, condiii care devin adevrate) care i modific starea (tranziie). Obs. Este indicat s se construiasc diagrame de stare numai pentru clasele din sistem care au un numr de stri bine definit i n care comportamentul clasei este influenat de acestea. Aceste diagrame intr n modurile de vizualizare design i de proces asupra sistemului. B3) Diagrama de activitate (Activity Diagram) Prezint activitile i responsabilitile elementelor sistemului. Diagramele de activitate au ca elemente constitutive stri de aciune (Action States) i mesaje care vor fi trimise sau recepionate ca parte a aciunii realizate. Reflect vederea dinamic de design i de proces i sunt utilizate pentru modelarea funciilor sistemului.

Seciuni (Views)
Seciunile 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. Seciunile UML sau modurile de vizualizare sunt grupuri de diagrame care se adreseaz unei anumite mulimi de concepte (entiti). Modelul captureaz cunotine i le comunic sub form de mod de vizualizare sau, pe scurt, view (arhitectural views). Fiecare view focalizeaz atenia 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 instituii. Un sistem poate fi descris lund n considerare urmtoarele aspecte: funcional - este descris structura static i comportamentul dinamic al sistemului; non-funcional - 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 numr de diagrame care conin informaii 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 funcionalitatea sistemului, aa cum este ea perceput de actorii externi care interacioneaz cu sistemul, precum i de utilizatorii acestuia, de diferii membri ai echipei realizatoare sau de alte sisteme. n componena lui intr diagramele cazurilor de utilizare pentru descrierea static a aspectului funcional i ocazional. Se pot folosi i diagrame de activitate pentru a ncapsula latura dinamic a funcionalitii. Cei interesai de aceast perspectiv sunt clienii, 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 cerinele funcionale ale acestuia, adic prezint serviciile asigurate de sistem utilizatorilor si. Vizualizarea logic trateaz din interior sistemul i descrie att structura intern a acestuia, format din clase, obiecte i relaii, ct i colaborrile care apar n urma schimbului de mesaje ntre obiecte, pentru a realiza funcionalitatea dorit. Structura static este descris de diagramele de clas i de obiecte, care includ elementele i relaiile care alctuiesc sistemul. Pentru modelarea dinamicii sistemului, se vor folosi diagrame de stare, de secven, de colaborare sau de activitate. Cei care sunt interesai 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, dependenele care exist ntre ele, resursele alocate acestora, precum i rezolvarea unor probleme legate de reutilizarea, portabilitatea codului, informaii administrative, cum ar fi un desfurtor al muncii de dezvoltare. Este folosit de dezvoltatorii sistemului, iar n componena 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 cerinele 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 interesai de o astfel de vizualizare a sistemului sunt dezvoltatorii i interogatorii de sistem.

V5) Modul de vizualizare desfurare sau mediu (The deployment or environment view) n acest mod de vizualizare sunt surprinse desfurarea 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 desfurare, care indic modul de implementare a sistemului. n acest sens, ele poart etichete care specific repartizarea pe tipuri de activitate i informaii despre procesele executate n noduri. De acest tip de vizualizare sunt interesai dezvoltatorii, interogatorii de sistem, precum i cei care realizeaz testarea sistemului.

Documente (Modele)
Un document este format dintr-un numr de seciuni care descriu un subiect comun i pot fi cri, articole etc.

Documentele UML sunt modele. Un model este o reprezentare a unui sistem. View-urile (seciunile) sunt grupate formnd 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 definete 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 cnd ar fi proprietatea lui. Putem stabili relaii ntre pachete, dar numai ntre tipuri, nu i ntre instane (pachetele nu au semantic definit de instane). Un pachet poate s aib vizibilitate, ca i clasele, prin care se precizeaz modalitatea prin care alte pachete pot s-i acceseze coninutul. 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 proiectrii. Notele sunt corespondentul comentariilor din limbajele de programare. Notele pot conine orice informaie, 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 colul dreapta sus ndoit, n interiorul cruia se afl informaia dorit.

Nota este ataat 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 neles specific asociat unui element. El se reprezint printr-un cuvnt ntre paranteze unghiulare duble (<< >>), scris deasupra sau dedesubtul numelui elementului asociat. Obs. Un stereotip transform un element n altul cu un neles nou. Exemplu. Dac se ataeaz stereotipul <<table>> clasei Examene, acesta va reprezenta o baz de date tabelar.

Proprieti
Proprietile sunt elemente de extindere UML, care lrgesc proprietile i semantica unui element UML. Ele se reprezint printr-o list de iruri de caractere ntre acolade ({ deasupra sau dedesubtul elementului UML. }), scrise

irurile de caractere care reprezint proprietile pot fi de dou forme: valoare etichetat (tagged value) - se exprim prin perechea "string = valoare" i reprezint caracteristicile unui element i valorile sale; constrngeri (constraints) - se exprim n OCL (Object Constraint Language) i reprezint condiiile pe care trebuie s le satisfac elementul. Exemplu. valorile etichetate ale clasei EXAMENE sunt versiunea i autorul, iar constrngerea este perioada de examene.

Reprezentarea grafic a elementelor de modelare

Reprezentarea grafic a elementelor de modelare (continuare)

Reprezentarea grafic a elementelor de modelare (continuare)