Diagrame de clase conceptuale n limbajul de modelare unificat (UML)

prof. dr. ing. Mircea Petrescu UML = limbaj de modelare vizual, orientat obiect, care descrie (reprezint) proprietile structurale i dinamice ale unui sistem software. Prin sistem software se ntelege o BD sau un modul de cod n general. Spre deosebire de modelul EAE, UML este o colecie de tehnici de modelare, folosite pentru tratarea multor aspecte ale procesului de concepere i dezvoltare a software-ului, de la proiectarea BD la interaciunea modulelor de cod. Fiecare tehnic de modelare de mai sus d o vedere diferit, static sau dinamic, a unei aplicaii. Colecia de vederi se numete model. Iat unele din tehnicile de modelare UML: diagrame de clase, sau diagrame statice de structur, care modeleaz entitile unui sistem prin clase cu atribute i comportare. Diagramele de clas descriu, de asemenea, asocierile dintre clase i constrngerile asupra acestora. Apoi, alte tehnici: diagrame de obiecte, diagrame de caz de utilizare, diagrame de stare, diagrame de secvene, diagrame de activitate, diagrame de colaborare. Clase UML Clasa UML modeleaz componentele (entitile) de interes ale unui sistem. Clasa are instane, sau realizri. Aceste instane sunt obiectele clasei. Prin conceptul de clas se descriu structura i comportarea obiectelor clasei. Structura conine atributele fiecrui obiect din clas. Comportarea include operaiunile ce pot fi executate (efectuate) pe (asupra) o instan specific de obiect. Notaia grafic pentru clasa UML: Nume de clas Atribute persistent Proiect + proiectId : char + location : string = Paris + cost : real create + newProject(); destroy + destroyProject(); standardAccess + getProjectId(); # setProjectId(string projectId); + getLocation(); # setLocation(string location); + getCost(); # setCost(real cost);

Operaiuni

Stereotipuri: irul de caractere aezat ntre ghilimele ( ) n partea de sus este un stereotip. Un stereotip reprezint un mod de a extinde semantica unui element de modelare, cum este o clas. n cazul de fa, stereotipul persistent identific clasa Proiect ca fiind o clas persistent. Clasa persistent este acea clas pentru care instanele sale persist n memorie dup ce procesul care a creat aceste instane a luat sfrit. n modelarea pentru bazele de date, stereotipul persistent indic faptul c o clas trebuie s fie reprezentat (realizat, mapped) printr-o reprezentare corespunztoare a bazei de date n timpul 1

implementrii. O clas fr stereotipul persistent reprezint un obiect tranzitoriu, care nu persist n memorie. Corespondene aici: relaii EDB (extensional schema) i IDB(intensional schema). Atribute Sintaxa de specificare a atributelor: [stereotype] [visibility] [/] attributeName [multiplicity] : [type] [=initialValue], n care: stereotype este un stereotip UML, definit de utilizator, pentru a mbogii semantica (nelesul!) unei definiii de atribut; visibility folosete simbolurile: + pentru vizibilitate public (orice clas poate avea acces la atribut); # pentru vizibilitate protejat (numai clasa respectiv i succesorii si pot avea acces la atribut); - pentru vizibilitate privat (numai clasa respectiv poate avea acces la atribut); / pentru a reprezenta un atribut derivat; attributeName reprezint numele atributului; multiplicity indic dac atributul este multi-valoare; type este un nume de clas, sau un tip de date, care definete tipul valorii ce se memoreaz n atribut initialValue indic o valoare lips (default) care trebuie atribuit atributului. Operaiuni Sintaxa prin lips (default) pentru specificarea semnturii unei metode este: [stereotype] [visibility] methodName ([parameterList]) : [returnType], n care: stereotype este un stereotip UML sau definit de utilizator pentru a mbogii semantica (nelesul) unei operaiuni; visibility folosete simbolurile: + pentru vizibilitate public (orice clas poate executa metoda); # pentru vizibilizate protejat (numai clasa i subclasele sale pot executa metoda); - pentru vizibilitate privat (numai clasa poate executa metoda); methodName reprezint numele metodei; parameterList este o list de atribute, sau de perechi de tipuri, separate prin virgule, pentru a indica parametrii formali ai metodei; returnType este numele clasei sau tipul de date care indic tipul valorii returnate (ntoarse) de o funcie. n cazul nostru: stereotipul create este un stereotip UML care identific o metod de constituire a instanelor de obiecte noi ale clasei; stereotipul destroy este un stereotip UML care indic metoda de distrugere a unei clase, pentru a elimina instanele de obiect; stereotipul standardAccess este un exemplu de stereotip definit de utilizator, care indic operaiile de atribuire i de extragere a valorilor de atribut ale unui obiect. Generalizare. Specializare n diagramele de clase UML se pot folosi operaiile de generalizare i specializare pentru a organiza clasele n ierarhii, de fapt ca n modelul EEA. Notaiile folosite n UML pentru generalizare i specializare sunt diferite fa de cele din EEA, dar sensul este acelai. Ca i n modelul EEA, mulimea instanelor pentru fiecare clas trebuie s respecte restricia ISA, prin care o instan a unei subclase este ntotdeauna o instan a superclasei sale. 2

Restriciile de specializare disjunctiv i de specializare total din EEA sunt valabile i n UML pentru ierarhiile de clase. De asemenea, diagramele UML accept subclase definite prin atribute, dei ntr-un mod mai restrns. Spre deosebire de modelul EEA, diagramele UML admit conceptul de clase abstracte, din programarea OO. Ne amintim c acest tip de clase nu poate fi instaniat n mod direct. Formarea ierarhiilor de clase n UML Notaii specifice pentru descrierea ierarhiilor claselor n UML: persistent Persoan persistent Arhitect persistent Constructor persistent Persoan persistent Arhitect persistent Constructor

(a) cu linii separate de subclas ntre (a) i (b) nu este diferen semantic.

(b) Cu linii de subsclas arborescente

Notaia de mai sus corespunde situaiei de apartenen disjunct a claselor (apartenena la o superclas a dou subclase disjuncte). Aceasta este o form de specializare a claselor. Pe lng reprezentarea de mai sus, de asemenea, n mod explicit, prin intermediul (cu ajutorul) restriciilor de specializare. Acestea sunt construcii (cuvinte, termeni) cuprinse ntre acolade (braces) i asociate cu legtura de specializare ntre o subclas i o superclas (mai sus se poate asocia {disjunct}). Restricii de specializare: Tip de restricie disjunct overlapping mandatory complete incomplete Descriere Indic subclase disjuncte Indic subclase care se suprapun Indic participare obligatorie n subclase Indic faptul c n ierarhie au fost specificate toate subclasele posibile Indic faptul c nu au fost specificate toate subclasele posibile

Restriciile de mai sus se refer la modul i gradul de participare i de apartenen a subclaselor n ierarhia de clase. n timp ce mandatory este o restricie definit de utilizator, toate cellalte restricii sunt definite de UML. Note. Restricia disjunct indic faptul c intersecia unei mulimi de subclase este mulimea vid. Adic, o instan a superclasei poate fi o instan numai a uneia din subclase. Overlapping indic faptul c o instan a superclasei poate fi o instan a mai multe subclase. Mandatory indic c fiecare instan a superclasei trebuie s fie o instan a cel puin uneia din subclasele sale. Complete i Incomplete arat c toate subclasele au fost indicate (ie sunt prezente!) n ierarhia de clase. Ne reamintim c atunci cnd ne-am ocupat de formarea ierarhiilor de clase n modelul EEA, am folosit exemplul (Persoana) (Arhitect, Constructor) (Edificii, Decoraiuni Interioare, Construcii Civile, Construcii Industriale), unde (Persoana) era n ierarhie clasa rdcin, sau de 3

baz. Tot n acel context au fost definite tipuri de restricii de specializare pentru modelul EEA (de fapt, care sunt aceleai ca n UML). S reprezentm acum ierarhia de clase Persoana n UML: persistent Persoana pId Nume Gen Telefon Adresa {disjunct} persistent Arhitect coala {disjunct, mandatory} persistent Edificii Nume edificiu persistent Decoraiuni interioare tip persistent Constructor Companie {disjunct, overlapping} persistent Construcii civile perioada persistent Construcii industriale tipuri

Observm aici c restricia mandatory (de obligativitate) corespunde restriciei de completitudine din modelul EEA, conducnd la o specializare total. Pe de alt parte, absena restriciei mandatory corespunde unei specializri pariale. Discriminatoare n contextul specializrii, att n EEA ct i n UML, funcioneaz apartenena unor instane la subclase pe baza valorii unui atribut de nivel de superclas. Acest atribut, care determin apartenena la o subclas, se numete discriminator. Observm c n UML folosirea unui discriminator implic ntotdeauna specializrile de tip disjunct i mandatory, respectiv aceste tipuri de apartenen la nivel de subclas. Iar o subclas trebuie s existe pentru toate valorile discriminatorului. Discriminatorul este specificat ca o etichet pe legtura de specializare i este considerat ca fiind un pseudoatribut al superclasei. Pseudoatributul se comport ca un atribut al unei clase obinuite, ns domeniul su este mulimea numelor de subclas. Remarcm c un pseudoatribut nu apare n zona de atribute de definiie a clasei. Exemplu: persistent ProiectExecuie Titlu persistent ProiectTehnic Descriere O clas abstract este indicat cu numele su n italic sau cu {abstract} sub numele clasei

type persistent Proiect IdProiect Amplasament

Cost Mai sus, discriminatorul este pseudoatributul type. Valori posibile pentru type sunt ProiectExecuie i ProiectTehnic. Discriminatorul implic specializare de tip mandatory la nivel de subclase. Ca urmare, clasa Proiect de mai sus este o clas abstract (de obicei, n italice). O clas abstract nu poate fi instaniat direct (adic instanele sale nu se pot crea direct). n cazul nostru, un obiect al clasei Proiect poate fi creat numai ca o instan a clasei ProiectExecuie sau a clasei ProiectTehnic. Prin restricia ISA, obiectul va fi automat i o instan a clasei Proiect. ntr-o ierarhie de clase pot fi mai multe discriminatoare. n acest caz, o instan a unei superclase trebuie specializat pentru fiecare discriminator, iar subclasele fiecrui discriminator trebuie s fie clase abstracte. Avem motenire multipl n acest caz (multiple instance). Clase abstracte i clase concrete O clas abstract primete instane n mod indirect, prin instanierea subclaselor sale. Drept rezultat, o clas abstract are ntotdeauna cel puin un nivel de subclase. Clasele abtracte ofer o manier mai direct, orientat obiect, pentru a specifica participarea total, aa cum aceasta este definit prin restricia de completitudine a modelului EEA. Fiecare instan a unei superclase abstracte este ntotdeauna o instan a cel puin unei subclase, deoarece obiectele pot fi create numai la nivel de subclas. Clasele concrete sunt cele care pot fi instaniate direct. n ierarhia din diagrama UML pentru Persoana, toate clasele sunt concrete. n ultimul exemplu, doar clasele ProiectExecuie i ProiectTehnic sunt concrete. n tratarea diagramelor de clase se ntlnesc operaiuni abstracte i operaiuni concrete. O operaiune abstract nu are implementare. Ea este ntotdeauna specificat ntr-o clas abstract, numele su fiind dat n italice sau cu {abstract} dup semntura metodei. Implementarea este realizat la nivelul unei clase concrete, care motenete aceast operaiune. O operaiune concret este aceea care are o implementare. Clasele abstracte pot avea operaiuni concrete. Asocieri Ca i n modelul EEA, legturile de diverse tipuri ntre mulimile entitate (1:1, 1:N, M:N) sunt denumite n UML asocieri (associations), nu relationship, ca n modelul de baz EA. Deci mai avem o problem de terminologie, deoarece atunci cnd am introdus modelul EA am tradus termenul relationship prin asociere. Diagramele de clase UML accept legturile de tip 1:1, 1:N, M:N ntre clase, fiind folosit termenul de asociere. Asocieri de baz n UML Pentru a indica o asociere ntre dou clase, se traseaz o linie. Cu aceste linii se pot asocia: nume de asocieri, nume de roluri, multipliciti, n vederea mbogirii coninutului semantic al descrierii asocierii. Exemplu: Sponsorizeaz > persistent 1 ... 1 0 ... * ProiectCercetare sponsorizatDe proiecteSponsorizate Se observ evoluia metodologiei de proiectare conceptual inclusiv n simbolurile utilizate n modelare. 5 persistent Sponsor

Terminologie: Numele asocierii Nume de roluri Multipliciti

sponsorizeaz sponsorizatDe proiecteSponsorizate 1 ... 1 0 ... *

O sgeat indic direcia citirii legturii (relationship) Un ProiectCercetare este sponsorizatDe un sponsor Un sponsor are mai multe proiecteSponsorizate Un proiectCercetare trebuie sponsorizatDe numai un singur sponsor Un sponsor poate s nu sponsorizeze nici unul, dar poate sponsoriza mai multe ProiecteCercetare

Ne reamintim c ideea de multiplicitate am ntlnit-o anterior, atunci cnd am folosit termenii de cardinalitate i opionalitate. Termenul multiplicitate este folosit n etapa actual a modelrii BDOR. Termenii de cardinalitate i opionalitate erau folosii ntr-o faz anterioar (10-12 ani!), cea n care se afirma modelul EEA, iar UML nici nu apruse. Notaia pentru multiplicitate n cazul asocierilor UML este prezentat mai jos: 0 ... * Se refer la zero sau mai multe obiecte Notaie min ... max (se refer la cel puin min 0 ... 1 Se refer la niciun obiect sau la cel mult un obiect obiecte i la cel mult 1 ... * Se refer la cel puin un obiect max obiecte) 1 ... 1 Se refer la exact un obiect 3 ... 5 Se refer la cel puin trei obiecte i la cel mult cinci obiecte Notaie prescurtat 1 La fel ca 1 ... 1 (shorthand) * La fel ca 0 ... * Multiplicitile n UML sunt similare cu perechile (min, max) din modelul EEA, dar sunt notate cu min ... max. n UML, atunci cnd descriem cu cte obiecte din clasa B poate fi asociat un obiect din clasa A, pereche min ... max este amplasat, pe linia asocierii, lng clasa B. Acest aranjament este diferit fa de cel al perechii (min, max) n cazul modelului EEA; n acest ultim caz, perechea (min, max) este asociat cu linia care unete clasa cu rombul legturii, indicnd de cte ori minimum i maximum un obiect al clasei particip la legtur (relationship). Valorile min i max au ns aceeai semnificaie cu privire la restriciile de cardinalitate i de participare din modelul EEA. De exemplu, un min pentru zero indic ntotdeauna o participare parial n asociere, pe cnd un min cu o valoare mai mare sau egal cu unu indic o participare total. Este interesant s examinm comparativ notaiile UML i EAE, aa cum sunt artate mai jos. Am ales cazul asocierilor 1:1. Notaia A 1 ... 1 0 ... 1 B UML Clasa A (un obiect din clasa A!) este asociat cu 0 ... 1 obiecte din clasa B (participare parial) Clasa B (un obiect din clasa B!) este asociat cu 1 ... 1 obiecte din clasa A (participare total) Notaia EAE echivalent este: 1 EAE EAE cu (min, max) A (0, 1) A

1 B

(1, 1)

n figura de mai sus, n asocierea dintre clasele A i B, obiectele din A au o participare parial n asociere, indicat prin valoarea min de 0 n perechea (min ... max) asociat cu B. n consecin, este

posibil pentru o instan din A s fie creat fr a se stabili o asociere cu un obiect din B. Pe de alt parte, obiectele din B au o participare total, indicat de valoare min de 1 n perechea (min ... max) asociat cu clasa A. Notm c fiecare obiect din B trebuie s fie asociat cu exact un obiect din A. n dezvoltarea diagramelor de clase UML pentru proiectarea conceptual a unei BD (obiectual relaional!), folosirea numelor de asocieri, a numelor de roluri i a multiplicitilor este opional. n fazele de nceput ale procesului de proiectare a unei baze de date, este acceptabil ca ntre dou clase s fie trasat numai o linie, pentru a marca faptul c exist o asociere. Totui, detaliile asocierii urmeaz a fi precizate (rafinate) n continuare, n procesul de proiectare. Cel puin, trebuie specificate multiplicitile nainte ca o diagram de clase UML s fie aplicat (mapped) pe un model specific de implementare (deci, transformat ntr-o implementare specific). Clase de asocieri i asocieri materializate Ne reamintim c n modelul EAE, asocierile (numite n acel model relationships) pot avea atribute. De exemplu, n cadrul unei asocieri M:N ntre mulimile entitate Proiectant i Proiect, un proiectant primete un salariu diferit pentru fiecare proiect la realizarea cruia particip. Desigur, valoarea salariului nu poate fi un atribut al entitilor Proiectant, deoarece un proiectant poate avea un salariu diferit pentru fiecare proiect la care lucreaz. De asemenea, nici entitile Proiect nu pot avea valoarea salariului ca atribut, ntruct un proiect poate folosi civa proiectani, care n general au salarii diferite. Modalitatea corect de a modela aceast situaie este ataarea unui atribut a asocierea mulimilor entitate Proiectant i Proiect. n diagramele de clase UML, atributele asocierilor pot fi modelate cu ajutorul claselor de asocieri. Un exemplu n continuare, pentru asocierea M:N cu numele Proiectanin, ntre mulimile entitate Proiectant i Proiect. n UML, la asocierea menionat, se ataeaz o clas de asociere, prin intermediul unei linii ntrerupte, aa cum se arat n figura de mai jos. Proiectanin persistent Proiectant 1 ... * 0 ... * persistent Proiect

persistent Salariat salariu

Clas de asociere

O clas de asociere are o zon de nume, pentru numele clasei, n cazul nostru Salariat. De asemenea, o clas de asociere poate avea o zon de atribute (n cazul nostru numai atributul salariu, care indic ce salariu primete un proiectant pentru fiecare proiect la care particip), precum i o zon de operaiuni. De notat c o clas de asociere poate participa n asocieri cu alte clase. O alt notaie legat de folosirea claselor de asociere este cea numit asocierea materializat (sau reificat). ntr-o asociere materializat, asocierea se modeleaz ca o clas, procesul de transformare a unei asocieri n clas fiind numit materializare, sau reificare. n aceast abordare, ceva care n aplicaia studiat nu este neles de obicei ca un obiect ca de exemplu, o asociere ntre dou clase , este modelat printr-o clas. S vedem cum se aplic procedeul de materializare (reificare) n cazul exemplului anterior. Evident, asocierea ntre clasele Proiectant i Proiect va fi transformat acum ntr-o clas de sine stttoare, cu numele Proiectanin (am folosit chiar numele asocierii), aa cum se vede mai jos: 7

persistent Proiectant

0 ... *

persistent Proiectanin salariu

1 ... *

persistent Proiect

Aa cum se vede, clasa Salariat a ncetat s fie o clas de asociere i a devenit o clas UML propriuzis, cu numele Proiectanin. Asocierea binar M:N ntre clasele Proiectant i Proiect a fost transformat n dou legturi (relationships) binare separate de tip 1:N una din ele leag Proiectant cu Proiectanin, iar cealalt leag Proiect cu Proiectanin. n noua abordare (reprezentare), fiecare instan a clasei Proiectanin este un obiect, care reprezint o legtur (asociere) ntre un proiectant i un proiect (de exemplu, pe partea 1 a fiecrei asocieri 1:N). De asemenea, deoarece un proiectant ar putea participa (lucra) la mai multe proiecte, partea N a asocierii 1:N ntre Proiectant i Proiectanin este descris ca fiind o multiplicitate 0...*. Aadar, prin procesul de materializare (reificare) asocierea M:N care conine o clas de asociere a fost reprezentat indirect prin dou asocieri 1:N, iar asocierea a fost reprezentat explicit printr-o clas de sine stttoare.