UML din perspectiva ORM

In lumea noastra competitiva si dinamica, afacerile necesita sisteme software de calitate care sa poata fi usor adaptate nevoilor curente. Aceste cerinte sunt cel mai bine modelate la un nivel inalt prin regulile de afaceri, care pot fi astfel usor validate de clienti si apoi transferate automat nivelului de implementare. UML (Unified Modeling Language) a devenit foarte folosit atat pentru modelarea bazelor de date cat si pentru modelarea software, iar versiunea 1.1 a fost adoptata in noiembrie 1997 de catre OMG (Object Management Group) drept limbaj standard pentru modelarea si proiectarea orientata obiect. Initial, bazat pe combinatia unor elemente utilizate de metodele Booch, OMT (Object Modeling Technique) si OOSE (Object-Oriented Software Engineering), UML a fost rafinat si extins de un consortiu de companii si apoi revizuit de OMG Revision Task Force.

UML include diagrame pentru cazurile de utilizare, structuri statice (diagramele claselor si obiectelor), de comportament (diagrame de stare, de activitate, secventiale si de colaborare) si de implementare (diagrame de componente si de aplicatie).

Pentru modelarea datelor, UML-ul foloseste diagrama claselor, unde constrangerile pot fi adaugate intr-un limbaj textual. Desi diagrama claselor include detalii de implementare (de exemplu, indicatori de navigare si de vizibilitate), in cadrul analizei este posibila omiterea acestor detalii din diagrama. Cand este astfel folosita, diagrama claselor reprezinta o extensie a notatiei Entitate-Relatie (ER).

Abordarea orientata obiect UML faciliteaza tranzitia catre codul orientat obiect, dar surprinderea si validarea regulilor de afaceri cu ajutorul expertilor in domeniu este stangace. Aceasta problema poate fi remediata prin folosirea unei abordari orientate pe fapte, unde comunicarea are loc prin propozitii simple, iar fiecare tip de propozitie poate fi usor populata cu instante mupltiple.

ORM Object Role Modeling) este o abordare orientata pe fapte care se potriveste bine cu UML, din moment ce amandoua furnizeaza suport direct pentru roluri, asociatii de aritate n si asociatii obiectificate. ORM ilustreaza lumea simplu, in termeni de obiecte (entitati sau valori) care au roluri (parti ale relatiei).

Avand in vedere ca cerintele afacerilor sunt continuu supuse schimbarilor, este necesar ca modelarea datelor sa se faca astfel incat impactul la aceste schimbari sa fie minim.

Cadrul ORM este mult mai stabil decat modelele orientat obiect sau ER, sub aspectul evidentierii schimbarilor din afaceri si faciliteaza mentinerea schimbarilor ce trebuie facute. Aceasta stabilitate se aplica nu numai modelului in sine, ci si problemelor conceptuale bazate pe model.

ORM poate fi folosit independent de alte metode, dar si impreuna cu ele. Pentru a beneficia mai bine de avantajele UML sau ER, ORM poate fi folosit pentru analiza conceptuala a regulilor de afaceri, iar modelul rezultat poate fi usor transformat in diagrama claselor UML sau intr-o diagrama ER.

O metoda de modelare include un limbaj si o procedura care foloseste limbajul pentru construirea modelului. Limbajele scrise pot fi grafice (diagrame) si/sau textuale. Modelele conceptuale descriu aplicatiile la nivelul de baza, folosind termeni si concepte familiare utilizatorilor viitoarei aplicatii. In comparatie cu acestea, modelele logice si fizice specifica fundamentul structurii bazei de date care va fi folosit pentru implementare, iar modelele externe specifica detaliile interactiunii cu utilizatorul (de exemplu, forma rapoartelor sau formularelor de pe ecran).

Criteriile de baza pentru evaluarea metodelor de modelare conceptuala sunt:

Expresivitatea unui limbaj se refera la mijloacele folosite pentru a exprima ceea ce poate fi modelat. Ideal ar fi ca un limbaj de modelare sa modeleze toate detaliile conceptuale relevante ale domeniului aplicatiei. Acesta este numit Principiul 100%. ORM este, in primul rand, o metoda pentru modelarea si interogarea unui sistem informatic la nivel conceptual, si pentru utilizat transpunerea acestuia la nivelul logic. Desi au fost propuse variante ORM extinse pentru modelarea orientata obiect si dinamica, ORM se concentreaza pe modelarea datelor, datorita faptului ca perspectiva datelor este mai stabila si asigura o baza formala pe care se pot definite operatii. In acest sens, UML-ul este mai expresiv decat standardul ORM, deoarece diagramele cazurilor de utilizare, de comporatament si de implementare modeleaza aspecte mai presus de structurile statice. Din acest punct de vedere, diagramele ORM sunt, grafic, mai expresive decat diagrama claselor UML. Mai mult, diagramele ORM pot fi folosite impreuna cu alte diagrame UML, si chiar pot fi transformate in diagrama claselor UML.

Claritatea unui limbaj se refera la usurinta cu care este inteles si folosit. In primul rand, un limbaj nu trebuie sa fie ambiguu. Sensul diagramelor sau expresiilor textuale trebuie sa fie intuitiv evident. In primul rand, un limbaj trebuie sa aiba concepte si notatii usor de invatat si de amintit.

Stabilitatea semantica se refera la cat de bine modelele sau interogarile exprimate in acel limbaj isi pastreaza sensul initial la aparitia schimbarilor in aplicatie. Un limbaj este mai putin stabil daca aparitia unor schimbari in cerintele aplicatiei necesita schimbari in model sau interogare.

Relevanta semantica cere ca doar detaliile conceptuale relevante sa fie modelate. Trebuie evitate aspectele irelevante scopului propus. Acesta este cunoscut drept Principiul de Conceptualizare.

Mecanisme de validare se refera la modurile in care expertii in domeniu verifica daca modelul se potriveste cu aplicatia. De exemplu, caracteristicile statice se pot verifica prin verbalizare si instantiere multipla, iar caracteristicile dinamice prin simulare.

Mecanismele de abstractizare se refera la modalitatile prin care detaliile nedorite din model, la un anumit moment, pot fi ascunse (sterse, scoase) din imaginea generala a acestuia. Acesta reprezinta un aspect important in cazul unui model de mari dimensiuni. Diagramele ORM au tendinta de a avea mai multe detalii si de a ocupa mai mult spatiu decat modelul corespunzator in UML, deci mecanismele de abstractizare sunt des folosite. Pot fi folosite diferite mecanisme pentru a ascunde sau arata parti relevante din model la un anumit moment, cum ar fi: modularizarea, nivelele de rafinare, stratificarea, dimensionarea obiectului. Cu mici modificari, aceste tehnici pot fi aplicate atat pentru ORM, cit si pentru UML.

Baza formala garanteaza ca modelele sunt clare si executabile. Ca avantaj particular, sunt permise corectii formale de echivalenta si implicatii intre modele alternative ale aceleiasi aplicatii. Desi notatia grafica a ORM este bogata si furnizeaza mai mult decat o tratare schematica a schemei de transformare, folosirea limbajelor de constrangere textuala poate doar partial sa diminueze acest avantaj. Atat UML, cat si ORM au o baza formala adecvata.

1. Referinta obiect

Dupa cum am aratat in capitolul precedent, ORM clasifica obiectele in entitati (obiecte nelexicale) si valori (obiecte lexicale), fiind necesar ca fiecare entitate sa fie identificata printr-o schema de referinta foarte bine definita. De exemplu, angajatul poate fi identificat prin matricola sau numarul asigurarii sociale ORM foloseste "obiect", "entitate" sau "valoare" cu sensul de "instanta obiect", "instanta entitate" si "instanta valoare", atasand "tip" pentru setul relevant al tuturor instantelor posibile. De exemplu, noi suntem instante ale tipului entitate Personal. Entitatile pot fi referite in mai multe moduri, si de obicei, isi schimba starea de-a lungul timpului. Valorile sunt constante (de exemplu, siruri de caractere sau numere) care se indica pe ele insasi, deci nu este necesara declararea schemei de referinta.

In Figura 1(a) este ilustrata explicit o schema de referinta simpla in ORM. Tipurile obiect sunt prezentate sub forma de elipse, folosind linii continue pentru tipurile entitate (Personal) si linii punctate pentru tipuri valoare (Nume). Tipurile relatie sunt prezentate ca fiind denumirea unei secvente dintr-un rol sau mai multe roluri, unde fiecare rol al obiectului apare intr-o caseta conectata la tipul obiect corespunzator. Numarul rolurilor reprezinta aritatea tipului relatie. In ORM, relatiile pot avea orice aritate (1=unara, 2= binara, 3= ternara, etc.), iar fiecare relatie trebuie sa fie elementara (o relatie care implica acelati tip obiect nu poate fi impartita in mai multe relatii fara pierdere de informatie). Din acest motiv, sunt rare aritatile mai mari de 5. In practica, aproape 80% din relatii sunt binare.

Figura 6 Schema de referinta simpla in ORM, prezentata (a) explicit, (b) implicit

Este responsabilitatea proiectantilor (nu a sistemului) de a impune constrangeri tipurilor de referinta primare. Aceasta este o problema conceptuala, nu de implementare. De exemplu, folosirea Matricola drept identificator extern nu garanteaza ca fiecarui angajat din lumea reala ii este atribuit doar o singura matricola. Exista diferite modalitati de verificare a datelor de intrare, dar chiar si in cazul celor extreme, cum ar fi verificarea AND, exista posibilitatea aparitiei de erori. Chiar si in cazul in care sunt impuse constrangeri pentru tipul referinta, sistemul poate fi acum folosit pentru a impune constrangeri pentru tipul fapta.

UML clasifica instantele in obiecte si valori de tip data. Obiectele din UML corespund, in principiu, entitatilor ORM, dar se presupune ca sunt identificate prin "oids". Valorile de tip date din UML corespund, in principiu, cu valorile ORM: sunt constante (de exemplu, siruri caractere sau numere) si de aceea nu necesita identificatori (oids) pentru stabilirea identitatii lor. Tipurile entitate sunt denumite clase in UML, iar tipurile valori sunt denumite tipuri data. De mentionat ca "obiect" inseamna "instanta obiect" si nu "tip obiect". O instanta a relatiei in UML este denumita legatura, iar un tip relatie poarta numele de asociatie

Din cauza puterii acestor identificatori (oids), in UML nu este necesar ca entitatile sa aiba o schema de referinta bazata pe valoare. Aceasta poate face imposibila comunicarea naturala la nivel de instanta si ignora cerintele aplicatiilor cu baze de date din lumea reala, care necesita o modalitate verbala de identificare a obiectelor. De aceea este important sa se includa referinta bazata pe valoare in orice diagrama a claselor UML, daca se dereste surprinderea tuturor etaliilor semantice conceptuale despre o clasa. Din pacate, pentru aceasta este nevoie, de obicei, de introducerea de extensii care nu fac parte din notatia standard UML.

2. Atribute cu o singura valoare

Ca si in cazul notatiei ER, UML-ul permite ca relatiile sa fie modelate ca atribute. De exemplu, in Figura 2(b), clasa Personal are opt atribute. In UML, clasele sunt simbolizate ca un dreptunghi, care poate include optional si alte compartimente pentru atribute si operatii. Diagrama ORM corespunzatoare este prezentata in Figura 2(a). Dupa cum are si numele, ORM modeleaza lumea doar in termeni de obiecte si roluri si are doar o singura structura de date si aume tipul relatie. Aceasta este una din diferentele fundamentale intre UML si ORM (si intre ER). Cand in UML se foloseste un atribut, in ORM se foloseste o relatie. Ca o prima consecinta, diagramele ORM de obicei ocupa mai mult spatiu decat diagramele corespunzatoare din UML sau ER. Dar acesta este un mic pret in comparatie cu rezultatele obtinute.

Figura 7 Tipuri de relatii ORM (a) descrise ca atribute in UML (b)

Din modelul ORM reiese ca angajatii sunt identificati prin matricola. Primele patru constrangeri obligatorii inseamna ca fiecare angajat din baza de date trebuie sa aiba inregistrat numele, functia, salariu si data angajarii. Urmatorul punct negru unde se conecteaza doua roluri reprezinta o constrangere obligatorie disjunctiva, indicand ca disjunctia dintre cele doua roluri este obligatorie (fiecare angajat are un numar de asigurare sociala sau pasaport, sau ambele). Desi fiecare rol din cele doua, luat individual, este optional, cel putin unul din ele trebuie indeplinit.

In UML, atributele sunt implicit obligatorii. In modelul ORM, predicatul unar "fumeaza" este optional (nu toata lumea trebuie sa fumeze). UML-ul nu permite relatii unare, si drept urmare se modeleaza prin atributul boolean "esteFumator". In UML, domeniul oricarui atribut poate fi, optional, afisat dupa atribut (precedat de doua puncte). In acest exemplu, a fost afisat domeniul doar pentru atributul "esteFumator". In modelul ORM, Ateliere este identificate prin cod (in loc de nume). Unele din aceste detalii ar putea fi transferate in UML prin adaugarea la numele domeniilor (de exemplu, Cod_atelier), dar acestea sunt mai mult domenii sintactice, decat semantice.

UML-ul nu are o notatie grafica pentru rolurile obligatorii disjuctive si de aceea, acest tip de constrangere trebuie exprimata ca text intr-o nota atasata (Figura 2(b) jos). Aceste constrageri textuale pot fi exprimate ca o informare sau intr-un limbaj formal interpretat de un instrument. Desi UML furnizeaza in acest scop, un Limbaj Obiectual pentru Constrangeri (Object Constraint Language (OCL)), nu obliga la folosirea lui, permitand utilizatorilor sa-si aleaga propriul limbaj (chiar cod program). Insa, acest lucru duce la scaderea portabilitatii modelului. Mai mult, capacitatea de citire a constrangerii este de obicei, slaba, comparativ cu verbalizarea din ORM.

Constrangerile de unicitate aplicate partii stangi a rolului din modelul ORM indica faptul ca fiecare angajat are cel mult un numar matricol, nume angajat, salariu, functie, data nasterii, numar asigurari sociale si numar pasaport. Predicatele unare au constrangere de unicitate implicita; deci, pentru fiecare angajat rolul "fumeaza" este, cel putin o data, instantiat (pentru oricare stare data a bazei de date). Toate aceste constrangeri de unicitate sunt surprinse implicit in modelul UML, in care atributele au implicit o singura valoare.

Constrangerile de unicitate aplicate partii drepte a rolului (incluzand schema de referinta Matricola) indica faptul ca fiecare matricola, numar asigurari sociale si numar pasaport se refera la cel mult un anagajat. UML-ul nu are o notatie standard pentru aceste "constrangeri de unicitate a atributului". Pentru notarea acestora s-a ales adaugarea intre paranteze a unor constrangeri textuale dupa numele atributelor (PK= cheie primara, U= unicitate, adaugand numere pentru cazurile in care aceeasi constrangere se poate aplica unei combinatii de atribute). Folosirea cheii primare nu implica faptul ca modelul trebuie implementat intr-o baza de date ce foloseste chei bazate pe valoare; se indica doar schema de identificare primara care poate fi folosita in comunicarea umana.

Deoarece UML-ul nu asigura o notatie grafica standard pentru aceste constrangeri, lasand in seama utilizatorilor specificarea constrangerilor, nu surprinde faptul ca multe modele intalnite in practica nu includ aceste constrangeri.

Principalele motive pentru care ORM-ul nu foloseste atributele cu o singura valoare, care sunt modelate in UML sunt urmatoarele:

Modelele cu atribute independente sunt mai stabile;

Interogarile cu atribute independente sunt mai stabile;

Modelele cu atribute independente sunt mai usor de populat cu instante multiple;

Modelele cu atribute independente usureaza verbalizarea in propozitii;

Modelele cu atribute independente reflecta mai bine conectivatea intre domeniile semantice;

Modelele cu atribute independente sunt mai simle si uniforme;

Modelele cu atribute independente fac mai usoara specificarea constrangerilor;

Modelele cu atribute independente evita decizii arbitrare de modelare;

Modelele cu atribute independente pot fi folosite pentru a obtine la cerere vederi ale atributelor.

Sa incepem cu stabilitatea semantica. Modelele si interogarile din ORM sunt mai stabile, deoarece sunt independente de schimbarile cauzate de evolutia atributelor in entitati sau relatii, sau invers. Sa consideram urmatorul tip fapta: "Personal lucreaza Ateliere". In abordarea ER sau orientata obiect se poate modela folosind un atribut pentru ateliere (de exemplu, in Figura 2(b)). Daca mai tarziu dorim sa inregistram angajatii unui atelier, va trebui sa introducem Atelier ca un tip entitate. In UML, legatura dintre loc de munca si Ateliere nu este clara acum. Pentru a clarifica aceasta legatura, va trebui sa schimbam atributul pentru loc de munca intr-o asociatie intre Personal si Atelier. Aceasta este o schimbare importanta in model. Mai mult, orice interogare sau cod bazat pe obiect care se refera la atributul atelier trebuie de asemenea sa fie modificata.

Un model ORM este, in primul rand, o retea legata de tipuri obiect si tipuri relatii. Tipurile obiect sunt domenii semantice care conecteaza lucrurile si care sunt intotdeauna vizibile. Aceasta conectivitate dezvaluie detalii relevante si permite modelelor ORM sa fie interogate direct, folosind parcurgerea cu ajutorul tipurilor obiect pentru a realiza uniunea conceptuala. De exemplu, pentru a afisa angajatii nascuti intr-o tara cu o populatie sub 10 milioane, vom formula o astfel de interogare in ORM: afiseaza fiecare Personal care este nascut intr-o Tara care are o populatie <10000000.

Evitarea atributelor duce, de asemenea, la o mai mare simplitate si uniformizare. De exemplu, nu sunt necesare notatii pentru a modifica constrangerile asupra unor relatii in constrangeri asupra atributelor sau constrangeri intre atribute si relatii. Alt motiv este minimizarea alegerii arbitrare de modelare (chiar si modelatorii experimentati nu agreaza uneori aceasta alegere de a modela unele caracteristici ca atribute sau relatii).

Tipurile de propozitii (si constrangeri) in ORM pot fi specificate fie textual, fie grafic. Ambele variante sunt formale, si pot fi automat transformate una in alta. Intr-o diagrama ORM, un predicat apare ca o denumire (nume), ca o succesiune continua de una sau mai multe casute rol. Deoarece aceste casute sunt dispuse liniar, tipurile fapta pot fi convenabil populate cu exemple continand instante fapta multiple, cate o coloana pentru fiecare rol. Aceasta permite ca toate tipurile fapta si constrangerile sa fie validate prin verbalizare la fel ca si esantionul de populatie. Comunicarea dintre modelator si expertul in domeniu poate astfel avea loc intr-un limbaj familiar, sprijinit prin verificarea cu ajutorul populatiei. Valoarea practica a acestor validari este considerabila, mai ales ca multi utilizatori considera ca este mai usor sa lucrezi cu instante, decat cu tipuri. Atributele si stilul asociatiilor in UML face mai greu de populat modelele cu instante multiple, si de obicei, duc la verbalizare nenaturala. UML-ul furnizeaza diagrame obiect pentru discutarea instantelor singure, dar acestea nu sunt de mare ajutor pentru discutarea populatiilor cu instante multiple.

Pentru rezultate concise, ORM include algoritmi de generare dinamica in stilul diagramelor ER, ca vederi asupra atributelor. Acesti algoritmi stabilesc diferite niveluri de importanta pentru tipurile obiect, in functie de constrangerile si rolurile curente, reafisand tipuri fapta mai putin importante, ca atribute ale unor tipuri fapta mai importante. Modelarea si mentenanta sunt procese iterative. Importanta unei caracteristici poate fi modificata in momentul aparitiei modelului global, aplicatia fiind modelata din perspectiva propriilor schimbarii. Pentru a promova stabilitatea semantica, ORM nu face promisiuni, angajamente despre importanta relativa in modelele sale de baza, insa ofera vederi dinamice. Faptele elementare sunt unitati conceptuale fundamentale ale informatiei, sunt uniform reprezentate ca relatii, iar modul de grupare in structuri nu reprezinta o problema conceptuala.

Pe scurt, daca se doreste folosirea ORM-ului pentru analiza, sau daca se doreste modelarea cu diagrama claselor UML, se pot folosi modelele ORM pentru obtinerea lor.

Atribute multivaloare

Sa presupunem ca ne intereseaza sa modelam numelor angajatilor si sporturile practicate de acestia (daca practica). In ORM am putea modela aceasta situatie, asa cum este prezentata in Figura 3(a). Punctul de rol obligatoriu insemna ca fiecare angajat are un nume. Absenta punctului de rol obligatoriu de la primul rol al tipului fapta "Practica" inseamna ca acest rol este optional (este posibil ca unii angajati sa nu practice nici un sport). Lipsa punctului de rol obligatoriu al rolurilor de la Nume si Sport nu implica optionalitatea acestor roluri. Daca in schema globala, un tip obiect are doar un rol fapta, acesta este implicit obligatoriu, doar daca tipul obiect nu a fost declarat independent. Deci, daca Nume si Sport nu au alte roluri in aplicatia finala, rolurile prezentate aici sunt implicit obligatorii.

Figura 3 "Practica" prezentat ca un tip fapta m:n in ORM (a) si ca un atribut multivaloare in UML (b)

Deoarece un angajat poate practica mai multe sporturi, iar un sport poate fi practicat de mai multi angajati, "Practica" este un tip relatie mai-multi-la-mai-multi. In ORM acest tip relatie se realizeaza prin extinderea constrangerii de unicitate asupra ambelor roluri. Vizual, se indica faptul ca pentru fiecare populatie a tipului fapta, doar combinatia de valori pentru cele doua roluri trebuie sa fie unica. Aceasta extindere a constrangerii de unicitate se aplica intotdeauna. Aceasta constrangere a fost prezentata doar pentru ca nu exista alta mai puternica. De exemplu, constrangerea de unicitate a tipului fapta Nume este mai puternica, pentru ca este extinsa asupra unui singur rol. Citind de la stanga la dreapta, tipul relatie Nume este mai-multi-la-unul (n:1), deoarece angajatii au cel mult un nume, dar acelasi nume il poate avea mai multi angajati.

O alternativa de modelare a aceleiasi situatii in UML este prezentata in Figura 3(b). Aici, informatia despre cine practica sport este modelata printr-un atributul multivaloare "sport". Atributului ii este adaugat "[0..*]" reprezentand o constrangere multivaloare, ce indica cate sporturi pot fi introduse pentru fiecare angajat. "0" indica posibilitatea ca pentru un anumit angajat sa nu se introduca nici un sport. Din pacate, standardul UML foloseste pentru acest caz valoarea nula, exact ca modelul relational. Prezenta valorii nule in baza modelului UML nu expune utilizatorii la o implementare de natura conceptuala, si adauga o complexitate considerabila semanticii interogarii. Prin restrictionarea structurilor de baza la tipuri fapta elementare, ORM evita notiunea de valori nule, permitand utilizatorilor sa perceapa modelele si interogarile ca doua simple valori logice. Simbolul "*" din [0..*] semnifica inexistenta unei limite superioare a numarului de sporturi pentru un singur angajat. Cu alte cuvinte, un angajat poate practica oricate sporturi, neinteresandu-ne numarul lor exact.

Asa cum am aratat in subcapitolul precedent, un atribut care nu are o constrangere de multiplicitate explicita este considerat ca fiind obligatoriu si cu o singura valoare (exact una). Aceasta poate fi reprezentata explicit prin adaugarea valorii "[1]" atributului relevant. De exemplu, pentru a indica explicit ca fiecare angajat are exact un nume, putem folosi "Nume [1]".

Constrangerile ORM sunt usor de realizat prin popularea tipurilor fapta cu exemple. Aceasta populare este foarte folositoare pentru verificarea constrangerilor aplicate asupra tipurilor de fapte. Aceasta caracteristica ORM de validare-prin exemple se aplica tuturor constrangerilor, nu doar celor obligatorii si de unicitate, pentru ca toate constrangerile sunt bazate pe rol si fiecarui rol ii corespunde o coloana din tabela faptelor.

In locul folosirii tabelelor de fapte in scopul instantierii, UML furnizeaza diagrama obiectelor. Acestea sunt in esenta diagrame ale claselor, unde fiecare obiect este prezentat ca fiind o instanta separata a clasei, furnizand valori de tip data atributelor sale.

Figura 4 Diagrama obiectelor pot fi folosite in UML pentru exemplificarea populatiei

Dupa cum se stie, UML-ul ofera posibilitatea de a modela o caracteristica ca atribut sau asociatie (similar cu un tip relatie ORM). Macar pentru analizele si interogarile conceptuale, asociatiile explicite prezinta mai multe avantaje pentru atribute, mai ales cele multivaloare. Aceasta posibilitate de a alege, ne ajuta sa verbalizam, vizualizam si populam asociatiile. De asemenea, ne permite sa exprimam constrangeri diferite pentru "rolul indeplinit de atribut" in notatia standard, in locul folosirii unor extensii care nu sunt standard (in loc sa folosim parantezele). Acestea se aplica nu numai constrangerilor simple, dar si celorlalte constrangeri (de frecventa, submultime, de excludere) asupra unuia sau mai multor roluri care include rolul indeplinit de domeniul atributului (in asociatia implicita corespunzatoare atributului.

Alt motiv care determina utilizarea asociatiei in locul atributelor este stabilitatea. Este posibil atat in ORM cat si in UML sa transformam o relatie in obiect si sa-i atasam noi detalii. In schimb, daca modelam ca atribut o caracteristica, nu putem adauga noile detalii fara modificarea schemei initiale: ca efect, va trebui sa inlocuim mai intai atributul cu o asociatie. De exemplu, consideram asociatia din Figura 3(a) Personal-practica-Sport. Daca am dori sa inregistram nivelul angajatului pentru jocul practicat, am putea simplu sa obiectivam asociatia ca Joc, si sa-i atasam tipul fapta: Jocul-are-NivelJoc. O modificare similara poate fi facuta in UML, daca ar fi fost modelata caracteristica Joc ca atribut. Oricum, in Figura 3(b) aceasta caracteristica este modelata ca atribut al sportului; deci, acest atribut trebuie eliminat si inlocuit cu asociatia echivalenta inainte de a putea adauga detaliile de nivel.

Alta problema ce apare in cazul atributelor multivaloare este interogarea asupra lor, fiind necesara o modalitate de extragere a anumitor componente, ceea ce complica procesul de interogare pentru utilizatori. Folosirea atributelor multivaloare in structuri mai complexe face mai dificila exprimarea cerintelor utilizatorilor.

Sintetizand cele spuse pana acum, putem spune ca:

Atributele in UML sunt descrise in ORM ca tipuri relatii.

instanta a relatiei in ORM este numita legatura in UML.

Un tip relatie in ORM este numita asociatie in UML.

Un rol este o parte indeplinita dintr-o relatie atat in UML cat si in ORM. Numarul rolurilor dintr-o relatie reprezinta aritatea relatiei.

In ORM este permisa orice aritate a relatiei. Fiecare tip relatie are cel putin un sens de citire sau nume predicat. O relatie de aritate n poate avea pana la n sensuri de citire (cate unul pentru fiecare rol), pentru a asigura verbalizarea naturala a constrangerilor si cai de navigare in orice directie. Un predicat este o propozitie elementara cu spatii libere in el pentru termenii obiectului.

In ORM, tipurile propozitii si constrangerile pot fi specificate textual sau grafic. In Visio, instrumentul InfoModeler poate transforma automat reprezentarea grafica in textuala si invers. Intr-o diagrama ORM, rolurile apar ca niste casute, legate de tipul obiecte printr-o linie. Un predicat apare ca o sceventa continua de denumiri ale casutelor rol. Pentru ca aceste casute sunt dispuse in linie, tipurile fapta pot fi convenabil populate cu ajutorul tabelelor ce contin instante multiple ale faptei, avand cate o coloana pentru fiecare rol. Aceasta permite ca tipurile fapta si constrangerile sa fie validate prin verbalizare la fel ca un esantion de populatie. Dialogul dintre modelator si expertul in domeniu are loc intr-un limbaj familiar, sprijinit de verificarea populatiei.

UML-ul foloseste atributele logice (booleene) in locul relatiilor unare, dar permite relatii de orice alta aritate. Fiecarei asociatii i se pot atribui cel mult un nume, acest lucru fiind optional. Asociatiile binare sunt reprezentate grafic ca linii ce leaga clasele. Liniile asociatiei pot avea forma de curba daca este nevoie (de exemplu, pentru relatiile circulare). Rolurile asociatiei apar simplu ca si capete ale liniei in loc de casute, dar pot avea optional nume pentru rol. Odata adaugate, numele rolului nu se mai poate renunta la el. Verbalizarea in cadrul propozitiilor este posibila doar pentru relatiile binare infix, si atunci doar pentru a denumi asociatia cu un nume predicat (de exemplu, "lucreaza") folosind un marcaj optional "►" pentru a indica directia.

Asociatiile ternare sau de aritate mai mare din UML sunt reprezentate ca romburi conectate prin linii la clase. Deoarece sunt folosite multe linii pentru a indica asociatia, verbalizarea directiei nu se poate realiza, astfel ca diagrama nu poate fi folosita pentru a realiza propozitii. Aceasta afisare neliniara nu este practica pentru popularea asociatiilor cu instante multiple. La aceasta se adauga si imposibilitatea afisarii populatiei multiple a atributelor, ceea ce face ca diagrama claselor sa nu poata fi folosita pentru verificarea cu ajutorul populatiei.

Pentru asociatiile binare, exista patru tipare posibile de constrangeri de multiplicitate ale rolului (n:1, 1:n, 1:1, m:n) si patru tipare posibile de constrangeri de obligativitate ale rolului (doar rolul stang obligatoriu, doar rolul drept obligatoriu, ambele roluri obligatorii, ambele roluri optionale). Daca restictionam frecventa la unu, exista 16 combinatii posibile de multiplicitate pentru asociatiile binare. Primele patru dintre acestea sunt prezentate in Figura 5, acoperind cazul in care ambele roluri sunt optionale.

Figura 5 Tipare echivalente de constrangeri in UML si ORM, pentru cazul in care ambele roluri sunt optionale

Urmatoarele patru cazuri, prezentate in Figura 6, acopera situatia in care primul rol este obligatoriu si al doilea rol este optional.

Figura 6 Tipare echivalente de constrangeri in UML si ORM, pentru cazul in care primul rol este obligatoriu

Urmatoarele patru cazuri, prezentate in Figura 7, acopera situatia in care primul rol este optional si al doilea rol este obligatoriu. In Figura 8, este prezentata situatia in care ambele roluri sunt obligatorii.

Figura 7 Tipare echivalente de constrangeri in UML si ORM, pentru cazul in care al doilea rol este obligatoriu

Figura 8 Tipare echivalente de constrangeri in UML si ORM, pentru cazul in care ambele roluri sunt optionale

4. Tipuri de asociatii

Asociatii calificate

Am aratat ca UML-ul nu are notatie grafica pentru surprinderea constrangerilor de unicitate externe asupra rolurilor din ORM, fiind remodelate ca atribute in UML. Totusi, se poate introduce o notatie proprie "" pentru adaugarea constrangerii asupra atributelor ca si constrangere textuala. Cazurile simple in care ORM-ul utilizeaza constrangeri de unicitate externe pentru coreferinta pot fi modelate in UML cu ajutorul asociatiilor calificate. Deci, in loc sa se evidentieze rolurile relevante sau tipurile obiect ca atribute, in ORM, UML-ul foloseste o clasa, alaturi de un calificator, prin care face legatura cu rolul relevant al asociatiei. In UML un calificator este un set de unul sau mai multe atribute, a caror valori pot fi folosite pentru a delimita clasa.

Conceptul ORM de constrangere de unicitate externa care poate fi aplicat unui set de roluri apartinand unuia sau mai multor predicate, furnizeaza o modalitate usoara, simpla de a surprinde toate asociatiile calificate si combinatiile unice de atribute din UML, la fel ca si alte cazuri ce nu pot fi exprimate in notatia grafica UML (de exemplu, cazurile predicatelor m:n). Ca de obicei, notatia ORM are avantajul ca faciliteaza validarea cu ajutorul verbalizarii si instantierii multiple.

Asociatii disjunctive

UML foloseste termenul de asociatie disjunctiva pentru una din multele asociatii ale unei clase, unde la un moment dat fiecare membru al clasei poate participa in cel mult una din aceste asociatii. Pentru a indica acest lucru, UML-ul foloseste o constrangerea disjunctiva intre asociatii, atasand sirul constrangere "" unei linii intrerupte ce leaga asociatiile relevante.

Utilizarea in cadrul UML-ului a acestui tip de constrangere este confuza, deoarece este folosita in sens excluziv si nu incluziv. O alternativa de genul "xor" ar fi mai putin ambigua, si mai sigura, chiar daca este artificiala. In acest caz, constrangerea inseamna ca disjunctia este si excluziva si obligatorie. Daca ar fi corecta varianta excluziva, constrangerea ar fi capturata in ORM cu ajutorul unei constrangeri disjunctive, reprezentata printr-un simbol "A" leagat de o linie intrerupta de rolurile relevante. Daca cealalta varianta ar fi corecta, trebuie adaugata o constrangere obligatorie disjunctiva asupra rolului.

Constrangerea disjunctiva din UML se aplica intre roluri singulare. Standardul impune ca aceste roluri trebuie sa apartina unor asociatii diferite. Astfel, UML-ul nu poate folosi o constrangere disjunctiva intre rolurile unui tip fapt circular. Constrangerea disjunctiva din ORM acopera aceasta situatie, la fel ca si alte cazuri ce nu pot fi exprimate in notatia grafica din UML. Constrangerea disjunctiva din ORM poate fi aplicata oricarui set compatibil de secvente rol, prin atasarea simbolului "A" de linia intrerupta a secventelor rol relevante. Ca exemplu banal, sa consideram diferenta dintre urmatoarele doua constrangeri: o persoana nu poate scrie si revizui o carte. ORM-ul face distinctie clara intre acestea doua prin notarea precisa a agumentelor constrangerii.

Am incercat pana acum sa trec in revista toate structurile de date de nivel inalt ce pot fi specificate cu ajutorul notatiei grafice in modelele de date ORM si in diagramele claselor UML. De asemenea, si tipurile colectie pot fi specificate in ORM si UML prin adnotari textuale. In tabelul nr.1 sunt rezumate diferentele dintre cele doua metode de modelare, cu respectarea termenilor si a notatiilor grafice (netextuale) pentru instantele si structurile de date.

= acoperire incompleta a conceptului corespunzator

5. Alte diferente dintre ORM si UML

ORM permite specificarea grafica a constrangerii de tip submultime intre orice pereche de scevente rol compatibile prin legarea lor cu ajutorul unei sageti intrerupte. Aceasta inseamna ca populatia secventei rol sursa trebuie sa fie o submultime a secventei rol tinta (cea spre care este indreptata sageata). Fiecare secventa poate include una sau mai multe roluri.

Ca mecanism de extensie, UML permite specificarea constrangerii de tip submultime intre toate asociatiile prin atasarea unei etichete constrangere "" alaturi de sageata intrerupta dintre asociatii. Oricum, UML-ul nu furnizeaza o notatie grafica pentru constrangerea de tip submultime intre roluri singulare sau intre parti asociatiilor.

In ORM, o constringere de egalitate intre doua secvente rol compatibile este prescurtarea de la doua constrangeri de tip submultime (cate una in fiecare directie), fiind reprezentata ca o sageata cu doua capete. Aceasta constrangere inseamna ca populatia secventelor de roluri trebuie sa fie egale intotdeauna. Daca doua roluri indeplinite de un tip obiect sunt obligatorii, atunci o constrangere de egalitate intre ele este implicita (desi nu este explicit afisata).

UML-ul nu are o notatie grafica pentru constrangerea de egalitate. Pentru toate asociatiile s-ar putea folosi doua constrangeri separate de tip submultime. S-ar putea, de asemenea, adauga o noua notatie, folosind "" inaintea unei sageti intrerupte intre asociatii, dar aceasta notatie nu ar fi intuitiva, deoarece directia nu ar avea nici o semnificatie (contrar cazului submultime).

In general, constringerile de egalitate in UML sunt specificate in mod normal ca si constrangeri textuale (comentarii intre acolade ""). Ca si constringerea textuala de egalitate din UML, aceasta este neobisnuita fata de constrangerea corespondenta din ORM (grafica sau verbalizata).

In ORM, o constrangere de valoare restrictioneaza populatia unui tip valoare la un set finit de valori specificate fie complet (enumerare), fie prin valori de inceput si sfarsit (domeniu), sau prin combinarea celor doua variante (mixturi). Valorile in sine sunt valori de tip data primitive, in principal fiind siruri de caractere sau numere. Constrangerea este afisata prin declararea valorilor posibile intre acolade, fie deasupra tipului valoare sau deasupra unui tip entitate cu referinta.

In UML, tipurile enumerare pot fi modelate ca si clase, cu valorile listate (oarecum intuitiv) ca atribute. Domeniile si mixturile pot fi specificate prin declararea unei constrangeri textuale intre acolade, folosind orice limbaj formal sau neformal.

In prezentul capitol din lucrare am incercat sa surprind o parte din diferentele care exista intre ORM si UML. De asemenea, am urmarit sa argumentez, pentru elementele cele mai uzuale, avantajele si dezavantajele folosirii in modelarea bazelor de date a ORM-ului sau UML-ului. Bineinteles, ca sfera de cuprindere a acestora se poate extinde asupra tuturor elementelor utilizate atat de ORM cat si de UML.