Se introduc conceptele UML fundamentale pentru modelarea domeniului: clase, asocieri si atribute (obiecte specifice) plecând de la exprimarea initiala a necesitatilor pentru studiul de caz "E-commerce" (vezi lectia 1-a). În final se studiaza posibilitatile de generalizare si structurare ale domeniului.
Exprimarea generala a nevoilor utilizatorului a condus la formalizarea cazurilor de utilizare, precum si a unor machete de interfata om-masina - IOM (vezi lectia 1-a). Aceste descrieri functionale vor servi ca puncte de intrare pentru descrierea dinamica a scenariilor de executie ale viitorului sistem.
Conceptia obiect se bazeaza însa, în principal, pe descrierea structurala, statica, a sistemului de realizat, sub forma de ansambluri de clase de programe, eventual regrupate în pachete. Cele mai bune clase candidat sunt acelea care rezulta dintr-o analiza a domeni 414e41e ului (numita adesea analiza specifica), adica concepte manipulate de expertii în domeniu.
Modelul UML al domeniului este alcatuit dintr-un ansamblu de diagrame de clasa în care nu este definita nici o operatie: clase conceptuale ale domeniului, asocieri între acestea, atribute ale acestora.
Cum identificam conceptele domeniului?
Sa ne referim la cazurile de utilizare precizate anterior.
Pentru acest caz, vom identifica urmatoarele concepte fundamentale: lucrarea, autorul, editorul.
În "Gestiunea cosului" exista urmatoarele concepte fundamentale: cosul, cartea.
"Efectuarea comenzii" lucreaza cu urmatoarele concepte fundamentale: comanda, cosul, clientul, cartea de credit.
Observatie
Modelarea nu tolereaza utilizarea mai multor nume pentru acelasi concept. În cazul nostru "lucrare " este sinonim cu "carte". În cele ce urmeaza vom pastra aceasta ultima denumire.
Definitii
Clasa - reprezinta descrierea abstracta a unui ansamblu de obiecte având aceleasi caracteristici.
Obiectul - este o entitate cu limite bine definite, având o identitate si înglobând o stare si un comportament. Un obiect este o instanta a unei clase.
Atributul - reprezinta un tip de informatie continut într-o clasa. Exemplu: viteza, cilindreea, numarul de înmatriculare, sunt atribute ale clasei "Autoturism".
Asocierea - este o relatie semantica durabila între doua clase. Exemplu: o persoana poate avea un autoturism. Observatie: Asocierea între concepte este implicit bidirectionala (un automobil poate fi posedat de o persoana).
Operatia - reprezinta un element de comportament (un serviciu) continut într-o clasa. Observatie: Cea mai frecventa eroare la crearea unui model al domeniului este acela de a reprezenta ceva ca pe un atribut în loc de concept. Recomandam urmatorul criteriu de departajare: daca nu putem cere unei entitati decât valoarea sa, atunci acea entitate este un atribut; daca îi putem pune mai multe întrebari, atunci avem de-a face cu un concept care are la rândul sau mai multe atribute si legaturi cu alte obiecte.
Odata identificate conceptele fundamentale, este util sa adaugam:
asocierile necesare pentru a lua în calcul relatiile între aceste concepte;
atributele necesare pentru a raspunde la necesitatile de informatii.
Sa ne referim la cazurile de utilizare din studiul nostru de caz:
Am vazut ca orice lucrare poate avea : titlu, autor, ISBN etc, dar si alte atribute, precum pret, data aparitiei, editor, limba, subtitlu si numar de pagini.
Observatii:
Autorul are o serie de caracteristici, precum nume, prenume s.a. Conform definitiei de mai sus el este un concept, legat de carte printr-o relatie care exprima faptul ca orice carte este scrisa de unul sau mai multi autori. În acelasi timp, un autor poate scrie mai multe carti.
Editorul are, la rândul sau, caracteristici precum nume, tara etc. Orice carte are un editor, dar un editor poate tipari mai multe titluri de carti.
Considerentele de mai sus ne conduc la elaborarea diagramei de clase conceptuale din figura 2_1.
Fig.2_1 Diagrama claselor conceptuale pentru
"Cautarea lucrarilor"
Pentru a reprezenta diagrama claselor conceptuale la gestionarea cosului, trebuie sa avem în vedere ca un client poate alege mai multe exemplare din aceeasi carte si ca avem nevoie de costul total al cosului. Acesta din urma se calculeaza plecând de la pretul cartilor selectionate, ceea ce ne conduce la un atribut "derivat": <</total>>.
Cum sa exprimam însa faptul ca mai multe exemplare din aceeasi carte pot figura în acelasi cos? Pentru aceasta exista doua solutii:
Prima solutie: Adaugam un concept intermediar numit "LinieCos", care reprezinta linii ale cosului virtual ce corespund fiecare unui titlu de carte dar care au un atribut numit "cantitate".
Aceasta solutie este reprezentata în figura 2_2. Observatie: Atributul /total al clasei Cos este diferit de atributul /total al clasei Linie Cos. Acesta este un exemplu clar de polimorfism: cele doua atribute difera prin faptul ca apartin unor clase diferite.
Fig.2_2 Diagrama claselor conceptuale pentru "Gestiunea
cosului"(prima solutie)
A doua solutie: Este mai eleganta dar mai sofisticata si consta în introducerea unei clase de asociere, legata de o relatie între doua clase si nu de o clasa propriu zisa. Fiecare instanta a clasei de asociere precizeaza relatia între cele doua clase.
În cazul nostru, LinieCos este asociata relatiei dintre Cos si Carte, în asa fel încât, unui obiect Cos legat de un obiect Carte sa i se poata asocia o instanta LinieCos care sa contina atributul <<cantitate>> si care sa precizeze câte carti de acest fel intentioneaza sa cumpere clientul. Acest lucru este reprezentat în diagrama din figura 2_3. Atributul <<cantitate>> este pozitionat implicit pe 1.
Fig.2_3 Diagrama claselor conceptuale pentru
"Gestiunea cosului"(a doua solutie)
Definitii:
Multiplicitate: La cele doua capete ale unei asocieri se pot face indicatii de multiplicitate. Ele specifica, sub forma unui interval, numarul de obiecte care pot participa la o relatie cu un obiect din alta clasa, în cadrul unei asocieri.
Agregare: Agregarea, marcata cu un romb vid, este un caz particular de asociere nesimetrica - cu alte cuvinte, un obiect dintr-o clasa este asociat mai multor obiecte din alta clasa. Agregarea exprima o relatie de "a contine", "este compus din" si din acest motiv n-are nevoie sa fie nominalizata. De exemplu, în figura 2_3 agregarea exprima clar faptul ca un obiect Cos contine mai multe obiecte Carte.
Atribut derivat: Este un atribut a carui valoare poate fi dedusa din alte atribute ale aceleiasi clase sau ale unei clase asociate. Analistul pastreaza acest atribut (care ar putea fi considerat redundant) daca el corespunde unui concept important pentru aplicatia respectiva. De exemplu, în figura 2_3 atributul /total al clasei LinieCos exprima costul total al exemplarelor ce vor fi comandate de client pentru o carte, iar atributul /total al clasei Cos arata costul total al cosului calculat din însumarea tuturor liniilor de cos.
Compunere: O compunere este o agregare mai puternica ce implica faptul ca:
obiectele dintr-o clasa asociate unui obiect din alta clasa compun de fapt acel obiect, cu alte cuvinte toate sunt la fel de importante si determinante pentru obiectul pe care îl compun;
durata de viata a obiectului compus este aceeasi cu a obiectelor care îl compun, cu alte cuvinte disparitia obiectului compus antreneaza nemijlocit disparitia tuturor componentelor sale.
În cazul reprezentat în figura 2_2, relatia de compunere dintre Cos si LinieCos arata ca:
o linie a cosului nu poate apartine decât unui singur cos, acesta din urma fiind determinat de totalitatea liniilor sale;
distrugerea cosului antreneaza distrugerea automata a tuturor liniilor sale.
Clasa de asociere: Este o asociere promovata la rang de clasa. Ea poseda atât caracteristicile unei asocieri cât si pe acelea ale unei clase si poate contine deci atribute care se valorizeaza pentru fiecare legatura. Referitor la cazul nostru (vezi figura 2_3), fiecare legatura între cos si o carte contine o valoare a atributului cantitate reprezentând o linie a cosului.
De îndata ce un client are ceva în cos, el poate efectua o comanda. Pentru aceasta, el trebuie sa trimita datele sale personale si informatiile necesare efectuarii platii.
O comanda este obligatoriu asociata unui client si unui cos. Un cos nu da totdeauna nastere unei comenzi. Un client poate avea mai multe comenzi. Comanda este caracterizata prin data la care are loc comanda, modul de plata, adresa livrarii (în cazul în care aceasta este diferita de adresa clientului), detalii referitoare la livrare, cheltuielile de transport si suma totala de plata (suma totala de plata = totalul cosului + cheltuielile de transport).
Clientul este caracterizat prin: nume, prenume, adresa postala, eventual adresa de e-mail si numele întreprinderii.
Vom considera în continuare ca modul de plata privilegiat este card-ul bancar. Informatiile referitoare la card-ul bancar sunt private. Card-ul bancar este un concept nou, având mai multe atribute, ca de exemplu tip, numar, data pâna la care este valabil etc, legate printr-o relatie de compunere, de clientul nostru.
Diagrama claselor conceptuale pentru cazul de utilizare "Efectuarea comenzii" este ilustrata în figura 2_4:
Fig.2_4 Diagrama claselor conceptuale pentru
"Efectuarea comenzii"
Modul de calcul al sumei totale de plata a fost mentionat în cadrul diagramei printr-o notatie speciala care leaga atributele care participa la calcul din cele doua concepte "Cos" si "Comanda".
Acest caz de utilizare, care se refera la posibilitatea unui client de a-si vizualiza propriile comenzi, nu face sa intervina concepte noi fata de cele cunoscute pâna în prezent. Adaugând un atribut suplimentar <<parola>> la clasa "Client" putem securiza consultarea comenzilor în curs pentru un anume client.
În figura 2_5 este reprezentata diagrama claselor conceptuale pentru cazul de utilizare Consultarea comenzilor în curs. Dupa cum se vede, clientul, folosindu-se de parola, poate accesa toate comenzile sale aflate în curs de efectuare.
Fig.2_5 Diagrama claselor conceptuale pentru
"Consultarea comenzilor în curs"
Libraria X a deschis deja un numar de raioane de specialitate. Cartile sunt deci clasate în cadrul catalogului pe raioane de specialitate
În acelasi timp, cartile pot apartine mai multor teme, nu neaparat disjuncte. De exemplu, o carte precum "UML pentru bazele de date" apartine cel putin temelor "Tehnologii obiect" si "Baze de date". De notat, de asemenea, ca o tema se poate descompune în subteme. De exemplu, "Tehnologii obiect" se poate descompune în "UML", "Java", "C++" etc.
Daca adaugam acestor noi concepte pe acelea cunoscute deja de carte, autor si editor, putem reprezenta diagrama claselor conceptuale pentru "Întretinerea catalogului" ca în figura 2_6:
Fig.2_6 Diagrama claselor conceptuale pentru
"Întretinerea catalogului"
Observatii
Subtema se reprezinta printr-o bucla (feedback informational) la conceptul "Tema" de care nu difera ca structura si continut. Simbolul de agregare (romb vid) arata ca o tema poate contine sau nu o subtema iar aceasta, la rândul ei o alta subtema s.a.m.d. Numarul temelor care pot contine subteme nu este limitat.
Între raion si carte exista un semn de compunere (romb plin), în sensul ca orice carte trebuie sa apartina unui raion. De asemenea, raioanele trebuie sa figureze în catalogul nostru (unul singur), prin urmare o relatie de compunere leaga si raionul de catalog.
O tema, împreuna cu subtemele sale, poate contine una sau mai multe carti - relatie de agregare. De asemenea, o carte poate face parte din mai multe teme.
Informatiile editoriale nu sunt înca complet stabilite si depind de creativitatea angajatilor. Aceste informatii vor cuprinde, probabil, reviste despre carti, subiectele lunii, o carte a zilei prezentata pe prima pagina a site-ului etc.
Nu se refera la concepte ale domeniului, ci mai curând de valori adaugate prin site-ul Web.
Site-ul este un concept pur informatic. Acesta nu este un concept al domeniului.
La fel ca în cazul precedent, help-ul on-line nu este un concept al domeniului.
Pentru a îmbunatati modelul nostru, vom cauta posibilitatle de factorizare, identificând si apoi extragând similitudinile dintre clase (atributele si asocierile similare).
În modelul domeniului nostru nu exista o generalizare evidenta. Rezulta ca o diagrama de clasa nu comporta neaparat relatii de mostenire, chiar daca este vorba de concepte obiect.
Totusi, am putea anticipa de pe acum o diversificare a ariei de actiune a întreprinderii "Libraria X". Aceasta si-ar putea propune, în viitorul apropiat, si vânzarea de discuri si casete video. În acest caz, o relatie de generalizare ar permite identificarea unei super-clase Articol, continând o serie de atribute comune, ca de exemplu titlul articolului, data aparitiei sau pretul acestuia. Clasele derivate Carte, Disc si Video ar mosteni aceste caracteristici, adaugând însa atribute specifice, ca de exemplu subtitlu, ISBN, limba - pentru Carte, durata pentru Disc, durata si formatul - pentru înregistrarea Video. În acest fel s-ar crea o structura supla si evolutiva (vezi figura 2_7).
Fig.2_7 Generalizare cu super-clasa Articol dupa diversificarea vânzarilor
O alta generalizare ar putea fi încercata în cazul diagramei claselor conceptuale la "Efectuarea comenzii" (figura 2_4).
Daca o comanda poseda atributul adresaLivr - la care trebuie livrata comanda - clientul, la rândul sau, dispune si el de o adresa - adresaPostala. Adresa de livrare difera de adresa postala a clientului (adresa de facturare) numai în cazul unui cadou adresat altei persoane. Ambele adrese au aceleasi caracteristici: nume, prenume, nrStrada, codPostal etc.
Aceste considerente ne conduc la realizarea diagramei conceptuale pentru "Efectuarea comenzii" cu generalizarea adresei din figura 2_8. Se observa ca, în acest caz, generalizarea nu se efectueaza prin introducerea unei super-clase ci prin utilizarea unor asocieri - roluri (factorizare prin asociere).
Fig.2_8 Diagrama conceptuala pentru
"Efectuarea comenzii" cu generalizare prin roluri
Observatii:
Clasa Client nu mosteneste clasa Adresa deoarece un client nu este un fel de adresa. În acest caz nu este nevoie de o super-clasa. Este însa corect sa spunem ca un client poseda o adresa de facturare si ca o comanda poseda o adresa de livrare, ambele adrese având aceeasi structura.
Asocierile Client - Adresa si Comanda - Adresa sunt specializate si îndeplinesc anumite roluri. Adresa de facturare este obligatorie si dispare în cazul în care dispare clientul (este deci o compunere). Adresa de livrare nu este obligatorie si ramâne o simpla asociere cu un indicator de multiplicitate 0..1 la capatul din spre Adresa.
Definitii:
Super-clasa: este o clasa generala, cuprinzând un nucleu de caracteristici comune, legata la una sau mai multe alte clase specializate (sub-clase) printr-o relatie de generalizare. Sub-clasa mosteneste nucleul de caracteristici ale super-clasei, adaugând, eventual si alte atribute specifice.
Clasa abstracta: este o clasa care nu se instantiaza direct si care reprezinta o pura abstractizare în vederea factorizarii proprietatilor sale. De regula, se noteaza cu caractere italice. În cazul nostru, clientul nu va cumpara articole, ci carti, discuri sau casete video.
Pachet: este un mecanism general de regrupare a elementelor UML, utilizat, în principal, în analiza si conceptia obiectelor pentru a regrupa clase si asocieri.
Pentru a structura modelul nostru, vom regrupa conceptele în ansambluri coerente utilizând în acest scop conceptul UML de pachet.
Daca facem o recapitulare a conceptelor identificate pâna în prezent, avem imaginea din figura 2_9.
Fig.2_9 Conceptele majore ale domeniului
Structurarea modelului este o operatie delicata, care se sprijina pe doua principii fundamentale: coerenta si independenta.
Pastrarea coerentei se refera la regruparea claselor care sunt apropiate din punct de vedere semantic. Un criteriu important este acela de a evalua durata de viata a instantelor conceptelor si a le regrupa pe cele având durate de viata apropiate. De exemplu, în cazul nostru, obiectele claselor Tema, Editor, Autor si Raion au durate de viata începând cu câteva luni pâna la câtiva ani. În schimb, instantele claselor Cos, LinieCos si Comanda au durate de viata mult mai scurte.
Realizarea independentei consta în minimizarea relatiilor între pachete, cu alte cuvinte a relatiilor dintre clasele apartinând unor pachete diferite.
Diagrama din figura 2_9 ne sugereaza deja decuparea modelului în doua pachete diferite care tin seama de principiile enumerate mai sus (vezi figura 2_10).
Cele doua pachete, care apar în figura 2_10, verifica principiile unei mari coerente interne si a unui slab cuplaj extern. O singura asociere traverseaza cele doua grupe de clase si anume aceea existenta între Carte si LinieCos. Daca împingem analiza mai departe, ne dam seama ca aceasta asociere este numai unidirectionala. Într-adevar, o LinieCos depinde de Cartea selectata de client, dar definirea unei carti nu depinde de ceea ce va fi scris ulterior în linia cosului sau. Dependenta dintre cele doua pachete este, asadar, redusa la minimum.
Fig.2_10 Diagrama pachetelor de clase ale
domeniului
Observatii:
Semnul "+" dinaintea atributelor domeniului arata ca acestea pot fi accesate prin functii exterioare claselor în care atributele sunt definite.
În pachetul Catalog putem adauga conceptul Colectie. Acesta din urma regrupeaza carti care apartin unui anume Editor. Nu toate cartile apartin unor colectii. Asocierea între Carte si Colectie este de tip agregare.
Putem introduce o asociere între Colectie si Editor de tip compunere (vezi figura 2_11). Dat fiind faptul ca aceasta asociere este, într-un fel, redundanta pentru schema noastra deoarece atât colectia cât si editorul au fost deja asociate cartii, ea poarta numele de asociere derivata.
Asocierile derivate se supun acelorasi principii ca si atributele derivate si se noteaza cu o linuta oblica peste legatura de asociere.
Fig.2_11 Introducerea unei asocieri derivate în
pachetul "Catalog"
Întrebari
Ce numim analiza domeniului?
Cum identificam conceptele domeniului? Referiti-va concret la cazurile de utilizare din cadrul aplicatiei "e-commerce".
Ce numim "clasa", "obiect", "atribut", "asociere", "operatie"? Care este eroarea de care trebuie sa ne ferim atunci când reprezentam un model al domeniului?
Desenati diagrama claselor conceptuale pentru "Cautarea lucrarilor". Explicati multiplicatorii de la capatul asocierilor între Carte si Editor si între Carte si Autor.
Reprezentati diagrama claselor conceptuale pentru "Gestionarea cosului". Câte solutii de reprezentare putem avea? Explicati avantajele si dezavantajele fiecarei solutii. Ce semnificatie are atributul derivat "/total" din cadrul clasei LinieCos? Dar atributul derivat "/total" din cadrul clasei Cos?
Care este diferenta între "agregare" si "compunere"? Exemplificati pe diagramele claselor conceptuale pentru "Gestionarea cosului".
Ce numim "clasa de asocieri"? Exemplificati pe diagramele claselor conceptuale pentru "Gestiunea cosului".
Reprezentati diagrama claselor conceptuale pentru "Efectuarea comenzii"? Explicati conceptul CardBancar. Cum se reprezinta o relatie între atribute, de exemplu relatia între "/suma" de plata a Comenzii si "/totalul" Cosului?
Reprezentati diagrama claselor conceptuale pentru "Întretinerea catalogului". Explicati reprezentarea ierarhiei "Tema - subtema". Explicati rolul raionului de carti.
Câte feluri de generalizare a conceptelor cunoasteti? Exemplificati generalizarea prin "super-clasa" si generalizarea prin utilizarea "rolurilor" (factorizare prin asociere).
Explicati conceptul UML de "pachet de clase". Câte pachete putem construi în cazul modelului de domeniu al aplicatiei noastre "e_commerce" si care sunt acestea?
Ce numim "asociere derivata"? Exemplificati prin introducerea conceptului de Colectie în pachetul Catalog.
Aplicatii practice
Fie aplicatia "Gestiunea materialelor", subsistem al sistemului de gestiune a productiei prezentat în Lectia 1, care are în vedere urmatoarele activitati:
1. Magazionerul actualizeaza întrarile/iesirile de materiale în fisa de magazie.
2. La coborârea stocului sub nivelul stocului critic:
a) Se cauta materialul în catalogul de materiale si se alege furnizorul;
b) Se stabileste cantitatea de aprovizionat;
3. Pentru toate materialele care se gasesc în situatia de la pct.2 se alcatuieste o lista de aprovizionare, care urmeaza sa fie trimisa responsabilului serviciului de aprovizionare pentru selectarea furnizorilor si aprobare.
4. Pentru fiecare linie din lista aprobata se completeaza comanda cu numele si adresa clientului, modalitatea de plata, adresa de livrare, detaliile privind transportul etc. Se calculeaza costul comenzii la care se adauga costul transportului.
5. Se expediaza serviciului clienti comenzile aprobate.
Actorii care intervin în aceasta aplicatie sunt: magazionerul, (sub)sistemul de gestiune a stocurilor, (sub)sistemul de lansare a comenzilor de aprovizionare, responsabilul serviciului de aprovizionare, clientul, (sub)sistemul de elaborare a comenzii de aprovizionat. Care dintre acestia sunt actori umani si care fac parte din categoria sistemelor automate de prelucrare?
Sa se reprezinte urmatoarele cazuri de utilizare ale acestei aplicatii prin diagrame specifice limbajului UML, marcând si relatiile dintre acestea:
Gestionarea fisei de magazie: gestiunea fiselor de magazie cu actualizarea stocurilor de materiale si semnalarea coborârii nivelului stocului sub valoarea stocului critic;
Cautarea materialelor: cautarea în catalogul de materiale si alcatuirea listei cu materialele de aprovizionat, cantitati, termene de livrare si furnizori posibili;
Gestionarea listei de aprovizionare: alcatuirea listei cu materiale de aprovizionat definitiva, prin stergerea, adaugarea sau modificarea liniilor din lista;
Efectuarea comenzii: alcatuirea comenzilor de materiale inclusiv calcularea pretului de transport în functie de adresa de livrare si, eventual, plata prin mijloace electronice; Expedierea comenzilor serviciului clienti.
Definiti principalele clase conceptuale pentru aplicatia "Gestiunea materialelor" enuntata mai sus.
Reprezentati diagrama claselor conceptuale pentru cazurile de utilizare mentionate mai sus.
___
|
