Sunteți pe pagina 1din 25

1

Modelarea UML a magazinului virtual al S.C . NEOSERV S.R.L.

n cadrul acestei etape se dorete modelarea unui sistem informatic modern, care s permit cumprarea on-line a produselor unui service auto. S-a ales soluia realizrii unui site web, n care orice vizitator este liber s navigheze i s caute informaii cu privire la produsele oferite de acel service auto. Dac va alege unul sau mai multe produse, le va pune intr-un co virtual, se poate informa cu privire la ceea ce are de pltit, iar in final poate comanda prin Internet livrarea acelor produse la domiciliu, dup ce a efectuat, prin card, plata acestora. n scopul simplificrii modelului ma voi referi, n cele ce urmeaz, numai la urmtoarele trei categorii de produse: Filtre: filtru aer, filtru polen, filtru combustibil i filtru ulei pentru diferite tipuri de categorii auto, de la diverse firme. Uleiuri: ulei motor auto, ulei motor motociclete, scutere, ulei motor autocamioane, ulei motor utilaje agricole, ulei de transmisie, uleiuri hidraulice, ulei servodirectia i ATF i ulei compresor. Tuning: evacuare sport, tuning caroserie, tuning interior. Exigene funcionale
1.

Vizitatorul interesat s navigheze pe site, va efectua cutri multiple, variate i Cutare pe cele trei categorii menionate (filtre, uleiuri, tuning); n cadrul fiecrei categorii, va efectua o cutare detaliat n funcie de anumite caracteristici:
-

eficiente, dup cum urmeaz :

Filtrele dup categorie, firm productoare etc.; Uleiurile dup categori, firm productor, destinaie etc; Tuning dup evacuare sport, tuning caroserie, tuning interior, firm productoare, etc.

Referinele lucrrii fiind mai mult sau mai puin precise, este preferabil s se furnizeze mai multe criterii de cutare. Persoana care navigheaz trebuie s poat alege un criteriu: produs, categorie, firm productoare etc, sau mai multe criterii simultan (vezi exemplul de formular de interfa om-main IOM pentru cutare rapid din figura 1). Ar fi de dorit ca rezultatele cutrii s fie disponibile pe o pagin i s poat fi uor parcurse i reclasate. Fig. 1
Cutare rapid Produs

Rezultatul cutrii: n lucrri corespund cutrii dumneavoastr ... Rezultate 1 m din n Clasamentul dup: Produs Categorie

Serviciul Max Datorit lui Max, primii prin e-mail notificarea noilor apariii n domeniul ... E-mailul dumneavoastr

1: Primul produs prezentare detaliat Imaginea produsului Produs, Categorie Condiii de livrare Pre

Punei n co

2: Al doilea produs prezentare detaliat Produs, Categorie Condiii de livrare Pre

Imaginea produsului

Punei n co

Formular de interfa om-main IOM pentru cutarea rapid Descoperirea Fiecare produs vndut n cadrul site-ului trebuie s fie prezentat n detaliu, punndu-se n eviden urmtoarele elemente: imagine (pentru majoritatea lucrrilor) care s poat fi, eventual, mrit; preul i disponibilitatea; comentarii ale clienilor;

tabl de materii detaliat, extrase, etc. (a se vedea, de exemplu, schia IOM a paginii de prezentare a fiei detaliate a lucrrii din figura 2).
4

Fia lucrrii ........................................................................... Prezentarea detaliat a produsului Imaginea produsului Produs, Categorie Condiii de livrare Pre Marc Model Caroserie ........... ........... ................ Combustibil ....................

Punei n co Recomandai aceast produs unui prieten!

................................................

IOM - Fia detaliat a lucrrii


2.

Dac ia hotrrea s comande produsul, atunci l va pune n coul virtual. Dac va

comanda mai multe produse, gestiunea coului i va oferi suma total de plat, cumprtorul avnd posibilitatea s renune la unele produse sau s adauge alte produse n co.
3.

Odat hotrt s comande coul, cumprtorul trebuie s ofere acele informaii, care

permit vnztorului s verifice modalitatea de plat i soldul existent, dup care, dac informaiile sunt satisfctoare, comanda, confirmat de ctre client va fi transmis Serviciului Clieni al magazinului, care se va ocupa mai departe de livrarea la termenul stabilit i n condiiile cunoscute de ctre client a comenzii. 4. Dac informaiile oferite de ctre client nu sunt satisfctoare, atunci clientul poate prsi magazinul i s revin atunci cnd va remedia aceste lipsuri. Coul virtual al clientului nu s eva pstra dac acesta prsete magazinul! 5. Dac o comand este n curs de a fi executat, atunci aceasta poate fi vizitat de ctre cumprtor cruia i se ofer toate detaliile achiziionrii (pre, condiii de livrare, data la care va primi marfa etc.).

Fig. 2 Date contact: Nume: Prenume: Adresa de facturare: Tel./Fax./Mobil: Email: Adresa de expeditie: Adresa: Cod postal: Persoana de contact: Tel./Fax./Mobil: Email: Produse comadate: 1. ..............................; buc...... 2. ..............................; buc...... 3. ..............................; buc...... Pre total produse comandate: Detalii transport: Asigurare suplimentara Da transport: Plata transportului: La expeditor Pre total: Formular Comand Exigene referitoare la calitate i performan 1. Se impune o prezentare clar a modului de navigare pe site i a modului de cutare a informaiei. Aceasta trebuie s fie completate de un help on-line puternic i disponibil n orice moment. 2. Formularul comenzii trebuie s fie simplu, iar informaiile referitoare la modul de plat (card, cont bancar etc.) s poat fi verificate on-line. 3. Sistemul trebuie s fie performant, s permit consultarea simultan pentru minim 1000 vizitatori, iar cutarea fiecrui produs s nu depeasc 30 de secunde.

Nu

La destinatar Transportator preferat......................

Restricii de conceptie Entiti i informaii Principalele entiti i informaii, care intervin n cadrul modelului sunt urmtoarele:

Entitatea Produs, care constituie, n cazul nostru, generalizarea categoriilor Filtre, Uleiuri i Tuning; Caracteristici genrale ale produslui, ca de exemplu: Pre, Termen de livrare, Cantitate n stoc; Atributele particulare fiecrei entiti n parte (Filtre, Uleiuri i Tuning); Subentitile Productor i Distribuitor pentru Filtre, Uleiuri i Tuning, fiecare cu atributele lor caracteristice; Entitatea Co cu subentitatea Linie co; Entitatea Comand cu atributele necesare efecturii unei comenzi pe Internet (data comenzii, modul de plat); Entitatea Client cu atributele sale de identificare a clientului (nume, prenume, adresa de facturare a comenzii, adresa de livrare a comenzii); Entitatea Card avnd cel puin atributele eseniale (tipul, numrul cardului i data de expirare).

Actualizarea detelor de referin Informaiile referitoare la produsele prezentate pe site provin, de regul, din dou surse complementare:

Prima servete la alimentarea bazei de date cu toate produsele noi; Cea de-a doua servete la actualizarea datelor referitoare la pre i starea stocului din catalog. Sursele menionate vor fi ncrcate automat, periodic, in baza de date. Orice alte informaii vor fi culese manual, cu ajutorul unor mici aplicaii intranet,

dedicate mbogirii datlor referitoare la produse de ctre gestionarul site-ului. Actualizarea din formularele site-ului

Datele din site-ul web, nregistrate n baza de date descriu coordonatele clienilor i caracteristicile comenzilor acestora. Coordonatele clienilor sunt memorate. n prima faz, ele permit trimiterea pachetului corespunztor comenzii. n faza a doua, acestea economisesc o nou colectare a datelor cu prilejul unei noi comenzi. Toate datele personale sunt protejate, iar confidenialitatea lor este garantat. Comenzile sunt nregistrate, apoi tratate ulterior de Serviciul Clieni. Clienii pot consulta istoricul tuturor comenzilor. Coul Coul navigatorului va fi salvat n baza de date. Durata sa de via nu va depi pe cea a vizitei utilizatorului. Piaa securizat Culegerea numrului cartelei de credit a clientului trenbuie s se efectueze securizat, criptnd transferul HTTP prin intermediul protocoluli SSL. Comanda i numrul cartelei de credit sunt stocate n baza de date pn la prelucrarea comenzii. Banca n cauz va valida tranzacia dup care, numrul cartelei de credit va fi suprimat din baza de date. Specificarea cerinelor conform cazurilor de utilizare a. Identificarea actorilor Pentrul site-ul www.neoserv.ro avem urmtorii actori umani: navigatorul: persoana care viziteaz site-ul; Web-master-ul: rolul angajailor care au n sarcin buna funcionare i ntreinerea siteului Web; serviciul clieni: rolul angajailor care se ocup cu urmrirea comenzilor-client; gestionarul site-ului: rolul angajailor responsabili de coninutul redacional al site-ului. De asemenea, avem n vedere:

sistemul informatic Nouti conectat la site-ul Web, care alimenteaz baza de date cu noile produse;

Gestiunea stocurilor, care servete la actualizarea datelor privind preul i stocul de produse din catalog. Aceste dou surse sunt ncrcate n baza de date n mod automat i periodic. Ansamblul actorilor este reprezentat n figura 3. Fig. 3

Navigatorul Web

Webmaster

Gestionarul site-ului Nouti

Serviciul clieni

Gestiunea stocurilor

Actorii site-ului www.neoserv.ro Observaii 1. Un actor reprezint un rol jucat de o entitate extern (utilizator uman, dispozitiv material sau alt sistem) care interacioneaz direct cu sistemul studiat. Un actor poate consulta sau modifica direct starea sistemului, emind sau primind mesaje purttoare de informaii.
2.

Actor este acela care beneficiaz de utilizarea sistemului. Eliminai, pe ct posibil,

actorii fizici n favoarea celor logici. Aceasta ne permite s depim tehnologiile de interfa care risc s evolueze i s identificm actorii logici, susceptibili de a fi reutilizai. De exemplu, chiar dac aceeai persoan fizic poate juca succesiv rolurile de Gestionar al site-ului i Webmaster fa de site-ul Web, este vorba de doi actori diferii, dou profiluri distincte.

b.

Identificarea cazurilor de utilizare

Un caz de utilizare reprezint un ansamblu de secvene de aciuni realizate de sistem, care produc un rezultat observabil interesant pentru un anume actor. Un caz de utilizare modeleaz un serviciu adus de sistem. El exprim interaciunile actori sistem i aduce o valoare adugat notabil respectivului actor. O eroare frecvent este aceea de a dori s se mearg prea n detaliu. Un caz de utilizare reprezint secvene de aciuni realizate de sistem, care reprezint n mod precis un obiectiv specific al actorului. Cazul de utilizare nu trebuie deci s se reduc la o singur secven i nici la o singur aciune. Pentru fiecare actor identificat anterior, s cercetm deci diferitele intenii specifice n care utilizeaz sistemul. A. Navigatorul Pentru Navigator (potenial client) distingem urmtoarele cazuri: Cutarea produselo;, Gestionarea coului; Efectuarea comenzii. n figura de mai jos este reprezentat diagrama complet a cazurilor de utilizare ale navigatorului i relaiile dintre acestea. Fig. 4
Cutare pe produse

<<extinde>>

Vizitator
<<extinde>>

Gestionare co virtual

Pia securizat

Navigator

Client

Efectuare comand i creare cont client Serviciul clieni Consultarea unei comenzi n curs

10

Administrare cont

Diagrama cazurilor de utilizare ale navigatorului i relaiile dintre acestea Observaii 1. Fiecare caz de utilizare trebuie s aib un obiectiv n sine i s poat fi realizat independent de altele. De exemplu, un navigator poate vizita site-ul cu unicul scop de a cuta lucrri, fr intenia de a cumpra. El poate s gestioneze un co virtual numai pentru a face o simulare sau pentru a obine un deviz. Toate aceste obiective sunt independente i autosuficiente, reprezentnd adevrate cazuri de utilizare. 2. Utilizarea sgeii n asocierea cu Serviciul Clieni semnaleaz un sens unic de transmitere a informaiei. B. Angajaii ntreprinderii Pentru cei doi angajai ai societii S.C. Neoserv S.R.L. Gestionarul site-ului i Webmaster, distingem urmtoarele cazuri de utilizare: ntrein catalogul, ceea ce face s intervin cele dou sisteme: Nouti i Gestiunea stocurilor; Asigurarea funcionalitii siteului i perfecionarea structurii, repectiv, Asigurarea funcionalitii reelei. Aceste cazuri de utilizare sunt reprezentate n figura 5 Fig. 5

ntreinerea catalogului

<<Actor>> Gestiunea Stocurilor

<<Actor>> <<extinde>> Nouti

Gestionarul site-ului

Asigurarea funcionalitii site-ului i perfecionarea structurii Asigurarea funcionalitii reelei

Webmasterul

Digrama cazurilor de utilizare pentru angajaii societii


11

S.C. Neoser S.R.L.

Relaiile dintre cazurile de utilizare Pentru a detalia diagrama cazurilor de utilizare, UML definete trei tipuri de relaii standard ntre cazurile de utilizare: relaia de incluziune, formalizat prin cuvntul-cheie <<include>>, n care cazul de relaia de extensie, formalizat prin cuvntul-cheie <<extinde>>, n care cazul de relaia de generalizare /specializare, reprezentat printr-o sgeat cu vrful alb ctre utilizare de baz ncorporeaz explicit un altul, ntr-o manier obligatorie; utilizare de baz ncorporeaz implicit un altul, de manier opional; elementul generalizant, n care cazurile de utilizare descendente motenesc descrierea generalizantului. Fiecare dintre acestea pot cuprinde interaciuni specifice suplimentare. Primele dou relaii se reprezint printr-o linie ntrerupt, n timp ce cea de-a treia se reprezint printr-o linie continu. n primele dou relaii, sgeata de la captul liniei ntrerupte marcheaz ce include, respectiv cine se extinde, cazul de utilizare aflat la captul fr sgeat marcnd cine include, respectiv cu ce se extinde. Cazul de utilizare Consultarea unei comenzi n curs apare n momentul n care navigatorul dorete s intre pe site-ul www.neoserv.ro pentru a trece n revist propriile comenzi i, eventual, a face unele completri. Evident, n acest caz el trebuie s se identifice cu un nume utilizator (user name) i parola (password) date de sistem, fr a mai fi obligat s furnizeze toate datele sale personale. Accesul este limitat numai la comenzile proprii. Clasamentul cazurilor de utilizare i planificarea proiectului Putem ierarhiza realizarea cazurilor de utilizare, innd cont de: prioritatea funcional determinat de serviciul Marketing al ntreprinderii; riscul tehnic estimat de eful de proiect. Un exemplu de ordine de abordare rezultat din evaluarea cazurilor de utilizare innd cont de criteriile de mai sus este dat n tabelul 1 Tabelul 1 Caz de utilizare Cutarea produselor Gestionarea coului Prioritate nalt nalt
12

Risc mediu sczut 2 3

Ordine de abordare

Efectuarea comenzii Consultarea comenzilor n curs Consultarea help-ului on-line ntreinerea catalogului ntreinerea site-ului

medie sczut

nalt mediu

4 6 7 1 5

sczut sczut nalt nalt medie sczut Clasamentul cazurilor de utilizare

Conform clasificrii de mai sus se poate elabora o planificare a proiectului care urmeaz ordinea de abordare menionat n ultima coloan a tabelului 1. Aceast ordine de abordare este deosebit de important, att pentru eful de proiect care trebuie s-i organizeze echipele cu care s atace proiectul i s planifice ntreaga aciune, ct i pentru conducerea ntreprinderii care trebuie s-i planifice resursele pe care s le pun la dispoziia proiectului n aa fel nct s nu ntrzie desfurarea acestuia. Observaii
1.

Efectuarea comenzii este de prioritate medie, deoarece navigatorul poate scoate la Accentul este pus pe ntreinerea catalogului i Cutarea produselor, care sunt

imprimant devizul i apoi poate comanda prin fax sau curier trimind plata prin pot.
2.

indispensabile n prim instan. 3. La nivelul riscurilor tehnice, eful de proiect a considerat ntreinerea catalogului ca avnd cel mai nalt nivel de risc, din cauza problemelor legate de integritatea informaiilor (actualizate semi-automat n baza de date) i necesitii de a dispune de un catalog valid i la zi. 4. Efectuarea comenzii este considerat, de asemenea, ca avnd un nivel nalt de risc, datorit problemelor de confidenialitate i de criptare ce trebuiesc rezolvate. 5. Unul din principiile Procesului Unificat rezultat din dezvoltarea orientat obiect bazat pe UML este acela de a identifica i nltura mai nti riscurile majore.
6.

Dac prioritatea este nalt i riscul de asemenea, cazul trebuie abordat n prim Dac prioritatea este sczut i riscul de asemenea, se poate lsa cazul printre ultimile

instan. De aceea, ntreinerea catalogului a fost situat pe primul loc n tabelul 1.


7.

de rezolvat (vezi Consultarea help-ului on-line n tabelul 1). 8. Atunci cnd cele dou criterii sunt antagoniste, eful de proiect trebuie s decid cntrind argumentele pro i contra i tratnd, eventual, cu clientul pentru a stabili ordinea de abordare a cazului de utilizare respectiv.
13

Identificarea conceptelor domeniului Modelul UML al domeniului este alctuit dintr-un ansamblu de diagrame de clas n care nu este definit nici o operaie: clase conceptuale ale domeniului, asocieri ntre acestea, atribute ale acestora. Modelul UML este alctuit dintr-un ansamblu de Diagrame de clas n care se reprezint: clasele conceptuale ale domeniului (n care nu este definit nicio operaie), asocieri ntre clase i atributele acestor clase. Caz de utilizare Cutarea produselor Gestiunea coului Efectuarea comenzii Definiii
1.

Concepte fundamentale produs, filtre, uleiuri, tuning, productor, distribuitor coul, produsul comanda, coul, clientul, cartea de credit

Clasa reprezint descrierea abstract a unui ansamblu de obiecte avnd aceleai Obiectul este o entitate cu limite bine definite, avnd o identitate i nglobnd o stare Atributul reprezint un tip de informaie coninut ntr-o clas. Exemplu: viteza, Asocierea este o relaie semantic durabil ntre dou clase. Exemplu: o persoan

caracteristici.
2.

i un comportament. Un obiect este o instan a unei clase.


3.

cilindre, numrul de nmatriculare, sunt atribute ale clasei Autoturism.


4.

poate avea un autoturism. Observaie: Asocierea ntre concepte este implicit bidirecional (un automobil poate fi posedat de o persoan).
5.

Operaia reprezint un element de comportament (un serviciu) coninut ntr-o clas.

Observaie: Cea mai frecvent eroare la crearea unui model al domeniului este acela de a reprezenta ceva ca pe un atribut n loc de concept. Recomandm urmtorul criteriu de departajare: dac nu putem cere unei entiti dect valoarea sa, atunci acea entitate este un atribut; dac i putem pune mai multe ntrebri, atunci avem de-a face cu un concept care are la rndul su mai multe atribute i legturi cu alte obiecte. Adugarea asocierilor i atributelor
14

a. Cutarea produselor Orice produs poate avea : pre, termen de livrare, cantitate n stoc, comune tuturor categoriilor de produse avute n vedere: filtre, uleiuri sau tuning. Acestea din urm se numesc produse derivate. Ele motenesc caracteristicile menionate i pot avea, la rndul lor, atribute specifice. Astfe, filtre conine n plus atributele: categorie, marc auto, model, serie caroserie, motor (benzin, motorin), uleiuri are atributele: categorie, prezentare (bidon X litri), caracteristici, iar produsul tuning are atributele: categorie, marc auto, model, serie de caroserie, numr ui. ntre clasa produs i clasele: filtre, uleiuri, tunig exist o relaie de generalizare particularizare reprezentat cu o sgeat cu vrful alb, ndreptat spre clasa genralizat. Casa produs este o clas de baz, virtual, care nu exist dect prin intermediul claselor derivate: filtre, uleiuri, tunig, care i motenesc atributele. Considerentele de mai sus ne conduc la elaborarea diagramei de clase conceptuale din figura 6.

15

Produs Pre Termen de livrare Cantitate n

Fig. 6

Filtre 1..* Categorie Marc auto Model Serie de caroserie 1..*

Uleiuri Categorie Prezentare (x litri) Caracteristi ci 1..* 1..* 1..* Productor Nume ar 1..*

Tuning 1..* Categorie Marc auto Model Serie de caroserie Nr. ui 1..*

1..*

1..* 1..*

Distribuitor Nume ar

1..*

Diagrama claselor conceptuale pentru Cutarea lucrrilor


b.

Gestionarea coului Pentru a reprezenta Diagrama claselor conceptuale pentru cazul de utilizare Gestiunea

coului, trebuie s avem n vedere c un client poate alege mai multe exemplare din acelai produs i c avem nevoie de costul total al coului. Acesta din urm se calculeaz plecnd de la preul produselor selecionate, ceea ce ne conduce la un atribut derivat: <</total>>.

16

Pentru a exprima faptul c mai multe exemplare, din acelai produs pot figura n acelai co exist dou soluii: Prima soluie: Adugm un concept intermediar numit LinieCo, care reprezint linii ale coului virtual ce corespund fiecare unui produs, dar care au un atribut numit cantitate. Aceast soluie este reprezentat n figura 7. Observaie: Atributul / total al clasei Co este diferit de atributul / total al clasei LinieCo. Acesta este un exemplu clar de polimorfism (cele dou atribute difer prin faptul c aparin unor clase diferite). Fig. 7
Co /total 1 0..* LinieCo cantitate /total 0..* Produs se refer la 1 Pre Termen de livrare Cantitate n

Diagrama claselor conceptuale pentru Gestiunea coului(prima soluie) A doua soluie: Const n introducerea unei clase de asociere, legat de o relaie ntre dou clase i nu de o clas propriu zis. Fiecare instan a clasei de asociere precizeaz relaia ntre cele dou clase. n cazul nostru, LinieCo este asociat relaiei dintre Co i Produs, n aa fel nct, unui obiect Co legat de un obiect Produs s i se poat asocia o instan LinieCo care s conin atributul <<cantitate>> i care s precizeze cte produse de acest fel intenioneaz s cumpere clientul. Acest lucru este reprezentat n diagrama din figura 8. Atributul <<cantitate>> este poziionat implicit pe 1.

17

Fig. 8
Co /total LinieCo cantitate=1 /total 0..* Produs Pre Termen de livrare Cantitate n

Diagrama claselor conceptuale pentru Gestiunea coului(a doua soluie) Definiii:


1.

Multiplicitate: La cele dou capete ale unei asocieri se pot face indicaii de

multiplicitate. Ele specific, sub forma unui interval, numrul de obiecte care pot participa la o relaie cu un obiect din alt clas, n cadrul unei asocieri.
2.

Agregare: Agregarea, marcat cu un romb vid, este un caz particular de asociere

nesimetric cu alte cuvinte, un obiect dintr-o clas este asociat mai multor obiecte din alt clas. Agregarea exprim o relaie de a conine, este compus din i din acest motiv n-are nevoie s fie nominalizat. De exemplu, n figura 2_3 agregarea exprim clar faptul c un obiect Co conine mai multe obiecte Carte.
3.

Atribut derivat: Este un atribut a crui valoare poate fi dedus din alte atribute ale

aceleiai clase sau ale unei clase asociate. Analistul pstreaz acest atribut (care ar putea fi considerat redundant) dac el corespunde unui concept important pentru aplicaia respectiv. De exemplu, n figura 2_3 atributul /total al clasei LinieCo exprim costul total al exemplarelor ce vor fi comandate de client pentru o carte, iar atributul /total al clasei Co arat costul total al coului calculat din nsumarea tuturor liniilor de co. Compunere: O compunere este o agregare mai puternic ce implic faptul c: obiectele dintr-o clas asociate unui obiect din alt clas compun de fapt acel obiect, cu alte cuvinte toate sunt la fel de importante i determinante pentru obiectul pe care l compun; durata de via a obiectului compus este aceeai cu a obiectelor care l compun, cu alte cuvinte dispariia obiectului compus antreneaz nemijlocit dispariia tuturor componentelor sale.
4.

Clasa de asociere: Este o asociere promovat la rang de clas. Ea posed att

caracteristicile unei asocieri ct i pe acelea ale unei clase i poate conine deci atribute care se
18

valorizeaz pentru fiecare legtur. Referitor la cazul nostru (vezi fig. 8), fiecare legtur ntre co i o carte conine o valoare a atributului cantitate reprezentnd o linie a coului.
c.

Efectuarea comenzii De ndat ce un client are ceva n co, el poate efectua o comand. Pentru aceasta, el

trebuie s trimit datele sale personale i informaiile necesare efecturii plii. O comand este obligatoriu asociat unui client i unui co. Un co nu d totdeauna natere unei comenzi. Un client poate avea mai multe comenzi. Comanda este caracterizat prin data la care are loc comanda, modul de plat, adresa livrrii (n cazul n care aceasta este diferit de adresa clientului), detalii referitoare la livrare, cheltuielile de transport i suma total de plat (suma total de plat = totalul coului + cheltuielile de transport). Clientul este caracterizat prin: nume, prenume, adresa potal, eventual adresa de email i numele ntreprinderii. Vom considera n continuare c modul de plat privilegiat este card-ul bancar. Informaiile referitoare la card-ul bancar sunt private. Card-ul bancar este un concept nou, avnd mai multe atribute, ca de exemplu tip, numr, data pn la care este valabil etc, legate printr-o relaie de compunere (simbolizat printr-un romb plim) de clientul nostru. Diagrama claselor conceptuale pentru cazul de utilizare Efectuarea comenzii este ilustrat n figura 9.

19

Fig. 9
Co
Nr. buc Obiect P.U. P.T.

Comand d natere la
Nr. buc Obiect P.U. P.T. Adresa Ch. Transp.

/total 1

0..1

/ suma=Co.total + cheltTransp

data modPlata=CB adresaLivr dataLivr cheltTransp /suma 0..* dorete o Client 1

CardBancar tip numr dataValiditate

0..1

nume prenume adresaPotal email [0..1] ntrepr[0..1] parol

Diagrama claselor conceptuale pentru cazul de utilizare Efectuarea comenzii Modul de calcul al sumei totale de plat a fost menionat n cadrul diagramei printr-o notaie special care leag atributele care particip la calcul din cele dou concepte Co i Comand. d. Consultarea comenzilor n curs Acest caz de utilizare, care se refer la posibilitatea unui client de a-i vizualiza propriile comenzi, nu face s intervin concepte noi fa de cele cunoscute pn n prezent. Adugnd un atribut suplimentar <<parola>> la clasa Client putem securiza consultarea comenzilor n curs, pentru un anume client. n figura 10 este reprezentat Diagrama Claselor Conceptuale pentru cazul de utilizare Consultarea comenzilor n curs. Dup cum se vede, clientul, folosindu-se de parol, poate accesa toate comenzile sale aflate n curs de efectuare.

20

Fig. 10

Comand Client nume prenume adresaPotal email [0..1] ntrepr[0..1] parola


Nr. buc Obiect P.U. P.T. Adresa Ch. Transp.

0..* consult_comenzile_sale

data modPlata=CB adresaLivr dataLivr cheltTransp /suma

Diagrama claselor conceptuale pentru Consultarea comenzilor n curs e. ntreinerea catalogului Service-ul are deja un numr de raioane de specialitate. Produsele sunt deci clasate n cadrul catalogului pe raioane de specialitate Dac adugm acestor noi concepte pe acelea cunoscute deja putem reprezenta diagrama claselor conceptuale pentru ntreinerea catalogului ca n figura 11.

21

Fig. 11

1 Catalog 1..* 1 1..* Produs Pre Termen de livrare Cantitate n Raion nume

Filtre 1..* Categorie Marc auto Model Serie de caroserie 1..*

Uleiuri Categorie Prezentare (x litri) Caracteristi ci 1..* 1..* 1..* Productor Nume ar 1..*

Tuning 1..* Categorie Marc auto Model Serie de caroserie Nr. ui 1..*

1..*

1..* 1..*

Distribuitor 1..* Nume ar

Diagrama claselor conceptuale pentru Cutarea lucrrilor

22

Observaii ntre raion i produs exist un semn de compunere (romb plin), n sensul c orice produs trebuie s aparin unui raion. De asemenea, raioanele trebuie s figureze n catalogul nostru (unul singur), prin urmare o relaie de compunere leag i raionul de catalog. ntreinerea site-ului Site-ul este un concept pur informatic. Acesta nu este un concept al domeniului. Consultarea help-ului on-line La fel ca n cazul precedent, help-ul on-line nu este un concept al domeniului. Generalizarea conceptelor O generalizare ar putea fi ncercat n cazul diagramei claselor conceptuale la Efectuarea comenzii (figura 12). Dac o comand posed atributul adresaLivr la care trebuie livrat comanda clientul, la rndul su, dispune i el de o adres - adresaPotal. Adresa de livrare difer de adresa potal a clientului (adresa de facturare) numai n cazul unui cadou adresat altei persoane. Ambele adrese au aceleai caracteristici: nume, prenume, nrStrada, codPotal etc. Aceste considerente ne conduc la realizarea diagramei conceptuale pentru Efectuarea comenzii cu generalizarea adresei din figura 12. Se observ c, n acest caz, generalizarea nu se efectueaz prin introducerea unei super-clase ci prin utilizarea unor asocieri roluri (factorizare prin asociere).

23

Fig. 12
Co
Nr. buc Obiect P.U. P.T.

d natere la 1 0..1

Comand
Nr. buc Obiect P.U. P.T. Adresa Ch. Transp.

adresaLivrare

/total

data modPlata=CB adresaLivr dataLivr cheltTransp /suma 0..1 Adresa 1 nume prenume nrStrada codPotal ora ar telefon[0..1]

0..* dorete o

CardBancar tip numr dataValiditate 0..1 1

Client parola email [0..1] ntrepr[0..1] adresaFacturaree 1 1

Diagrama conceptual pentru Efectuarea comenzii cu generalizare prin roluri

Observaii:
1.

Clasa Client nu motenete clasa Adresa deoarece un client nu este un fel de adres. n

acest caz nu este nevoie de o super-clas. Este ns corect s spunem c un client posed o adres de facturare i c o comand posed o adres de livrare, ambele adrese avnd aceeai structur.
2.

Asocierile Client Adresa i Comanda Adresa sunt specializate i ndeplinesc

anumite roluri. Adresa de facturare este obligatorie i dispare n cazul n care dispare clientul (este deci o compunere). Adresa de livrare nu este obligatorie i rmne o simpl asociere cu un indicator de multiplicitate 0..1 la captul din spre Adresa.

24

Definiii:
1.

Super-clasa: este o clas general, cuprinznd un nucleu de caracteristici comune,

legat la una sau mai multe alte clase specializate (sub-clase) printr-o relaie de generalizare. Sub-clasa motenete nucleul de caracteristici ale super-clasei, adugnd, eventual i alte atribute specifice.
2.

Clasa abstract: este o clas care nu se instaniaz direct i care reprezint o pur

abstractizare n vederea factorizrii proprietilor sale. De regul, se noteaz cu caractere italice. n cazul nostru, clientul nu va cumpra articole, ci cri, discuri sau casete video.
3.

Pachet: este un mecanism general de regrupare a elementelor UML, utilizat, n

principal, n analiza i concepia obiectelor pentru a regrupa clase i asocieri.

25