PROBLEME CU PROBLEME

PREFA

Aceast lucrare s-a dorit a fi un efort conjugat al studenilor Universitii Titu Maiorescu,
facultile de tiine Economice i tiina i Tehnologia Informaiei.
Noi, cei care am contribuit la culegerea Probleme cu probleme, am studiat diverse
modele de sisteme informatice i am propus viziunea proprie de rezolvare i de
reprezentare a acestora cu ajutorul diagramelor UML.
Se va vedea totui diferena n interpretare a studenilor celor dou faculti. n vreme ce
studenii de la Facultatea de tiine Economice au studiat n profunzime cazurile din
punctul de vedere al sistemelor informatice n economie, studenii de la Facultatea de
tiina i Tehnologia Informaiei au pus accent pe crearea codului care s implementeze
modelul ales.
Sperm c acest lucru vine n ajutorul celor care sunt interesai de studiile de caz din
aceast culegere, pentru c prezint viziuni diferite.
Soluiile noastre nu sunt nici de departe unice, perfecte i, evident, nici complete. Acestea
pot fi mbuntite i suntem recunosctori tuturor celor care i pot aduce aportul la
completarea efortului nostru.
Dorim s mulumim pe aceast cale, ndrumtoarei noastre, doamnei Prof. Univ. Dr.
Mioara Udric, cea care ne-a oferit ideea i oportunitatea acestei lucrri.
Sperm ca aceast culegere s v fie de folos ntr-un fel sau altul
Colectivul de autori ai soluiilor implementate n aceast culegere

Colectiv de redacie:
Lupoaie Andra Elena

naintea prezentrii studiilor de caz din aceast culegere, vom trece n revist civa din
termenii care stau la baza lor, pentru o nelegere ct mai complet. Aceti termeni sunt
definii cu sensul din domeniul informatic:
Cuvnt
Sistem

Subsistem
Decizie

Dat

DICIONAR INFORMATIC
Sistem de gestiune a bazelor de date:
Totalitatea programelor utilizate pentru crearea, interogarea i
ntreinerea unei baze de date.
Sistem de operare:
1. Ansamblu de programe ce realizeaz gestiunea resurselor unui
sistem de calcul. Sistemul de operare asigur exploatarea eficient a
acestor resurse i rezolv conflictele care apar ntre diferii utilizatori.
2. Colecia organizat de programe, specifice tipurilor de echipamente
din componena unui sistem de calcul, care asigur: creterea eficienei
utilizrii resurselor; asistarea utilizatorilor; asistarea operatorilor;
asistarea personalului de exploatare i a personalului de ntreinere.
Component structural principal, subordonat unui sistem.
Aciune de determinare a modului de evoluie a rezolvrii unei
probleme sau a unei activiti cu calculatorul din mai multe alternative
posibile, n funcie de satisfacerea unei condiii. La nivelul unui limbaj
de programare, decizia este specificat prin instruciuni de control
condiionat; n cadrul unei- organigrame, decizia se simbolizeaz
folosind blocuri de decizie.
1. Numr, mrime, relaie etc. care servete la rezolvarea unei probleme
sau care este obinut n urma unei cercetri, urmnd a fi supus unor
corectri.
2. Reprezentare accesibil unui procesor, a informaiei prelucrate. O
dat este caracterizat prin valorile pe care le poate avea, prin operaiile
primitive de transformare, prin structura sa.

Informaie

Procedur

Cunoatere n general, adic apariia unui element nou, necunoscut

anterior, fie pentru om, fie pentru sistemul de calcul, asupra relaiei
nconjurtoare; n acest scop se utilizeaz simboluri care, prin asocierea
lor cu realitatea, furnizeaz informaii. Sistemele de calcul prelucreaz
informaii. Astfel, datele furnizate la ieire pot reprezenta o anumit
informaie pentru un utilizator, respectiv pot avea semnificaii deosebite
pentru diferii utilizatori.
1. Secven de operaii executate n scopul rezolvrii unei probleme
date.
2. Modul de program ce poate fi apelat din mai multe puncte ale unor
module de program, de obicei la nivelul unui limbaj de programare de
nivel nalt,executnd prelucrri determinate asupra unor date
communicate n momentul apelului.
2

Proces

Evoluie n timp. Particularizrile utilizate n informatic pentru acest

termen foarte general se refer la dou aspecte principale: procese
studiate i/sau controlate cu sistemele de calcul i procese care se
studiaz n sistemele de calcul. n primul caz, definirea procesului este
specific disciplinelor n care sunt studiate (fizic, chimie, tehnic) i
este preluat ca atare n informatic. n ceea ce privete procesele care
se studiaz n sistemele de calcul, o definire unanim acceptat nu a fost
elaborat pn n prezent, evoluia prelucrrilor fiind caracterizat, mai
definitoriu, prin sarcini.
Intranet
Este o reea local cu arhitectura bazat pe tehnologia internet i care
permite comunicarea pentru un grup nchis de utilizatori care
construiesc o baz comun de informaii.
Extranet
Este o aplicaie special ce permite unor organizaii accesul la
informaiile furnizate pe intranet.
Internet
Un sistem mondial de reele de calculatoare interconectate, care
nlesnete serviciile de comunicare a datelor, cum ar fi: deschiderea
unei sesiuni de lucru de la distan, transferul de fiiere, pota
electronic i grupurile de discuii.
Tehnologie
Ansamblul proceselor, metodelor, operaiilor etc. utilizate n scopul
obinerii unui anumit produs.
Birotic
Ansamblu de tehnici i mijloace care tind s automatizeze activitile
de birou, n special aspectele legate de comunicaie prin cuvnt scris
sau printr-o imagine.
Implementa
Faz a activitii sistematice de programare n scopul obinerii
produsului program finit, pe baza proiectului acestuia, prin codificarea
i testarea modulelor programului i integrarea lor n cadrul acestuia.
Activitatea de integrare urmrete construirea i testarea treptat a
programului pe baza modulelor competente.
Metodologie/m (Iterativ) aplicarea repetat a unui procedeu de calcul pentru obinerea
etod
soluiei unei probleme. Fiecare repetare (iteraie) utilizeaz valorile
calculate n pasul de iteraie precedent pentru a calcula valori mai
apropiate de soluia dat. Numrul de iteraii este dependent de precizia
dorit. Dac procedeul iterativ este convergent pentru o precizie dat,
numrul de iteraii este limitat. Valorile calculate n fiecare iteraie pot
fi considerate ca termeni ai unui ir, care, dac este convergent,
definete o metod iterativ convergent, limita irului reprezentnd
soluia calculat.
Proiecta
Proiectare logica :
1. Sinteza unei scheme logice, care implementeaz un set de funcii
specificat.
2. Etap a proiectrii unui sistem informatic sau al unui produs program
n care se definete modelul general, la nivel logic, independent de
forma de implementare.
Analist
Specialist care ndeplinete sarcinile: analizeaz i evalueaz sistemul
informaional/informatic existent, definete mpreun cu utilizatorii
cerinele informationale i construiete modelul logic al noului sistem,
3

Algoritm

Agregare
Generalizare
Motenire
Polimorfism

Diagram

Scenariu
Variabil

Atribut

proiecteaz i ntocmete instruciunile de executare a procedurilor

manuale din sistem, evalueaz gradul n care noul sistem dat n
exploatare satisface cerinele utilizatorilor, face propuneri de
modificare i dezvoltare. Analistul trebuie s posede cunotine
aprofundate n domeniul organizrii i conducerii, al modelrii
matematice i al cercetrii operaionale, al ingineriei sistemelor, s aib
cunotine generale despre echipamente i prelucrarea automat a
datelor, despre implicaiile psihologice i sociale ale introducerii
sistemelor informatice.
Concept folosit n mod intuitiv pentru a desemna o mulime finit de
operaii cunoscute, care, executate ntr-o ordine bine stabilit, pornind
de la un set de valori- intrarea a.- ce aparine unei mulimi de asemenea
seturi, multime numit domeniul de definiie al a., produc n timp finit
un alt set de valori- iesirea a.-. Algoritmul are 3 caracteristici
principale: 1.determinismul, 2. universalitatea, 3. finitudinea.
Este o relaie de tip parte-ntreg n care obiecte ce reprezint
componente ale unui ntreg sunt asociate cu ntregul. Agregarea este un
caz particular de asociere i nu este un concept independent.
Este o relaie dintre o clas de baz i una sau mai multe clase derivate
ale ei.
Evidentiaz partajarea atributelor i operaiilor de-a lungul unei ierarhii
ntre clase i subclase. Motenirea permite construirea de noi tipuri de
obiecte i clase evitnd rescrierea i recodificarea.
Definete caracteristica unei operaii de a se comporta n mod diferit n
funcie de clasa de obiecte creia i aparine. El permite invocarea
pentru obiecte de diferite tipuri a operaiilor cu acelai nume
(semntura), dar semantic i implementare diferite.
D. UML: sunt mijloace de reprezentare i vizualizare a elementelor de
modelare. (D. de stri), graf orientat, utilizat pentru descrierea
transformrii de intrare/ieire realizat de un automat. Nodurile grafului
reprezint strile automatului, iar arcele indic modul de efectuare a
tranziiilor ntre stri. (D. de timp), reprezentare a variaiei n funcie de
timp a unuia sau mai multor semnale electrice.
Reprezint parcurgerea diferitelor drumuri (situaii) prezentate ntr-un
caz de utilizare.
Construcie utilizat n limbajele de programare de nivel nalt, pentru
reprezentarea n program a valorii unei date, indivizibile n raport cu
prelucrrile specificabile n limbaj, i care poate fi modificat pe
parcursul execuiei programului sau pentru execuii diferite ale
acestuia. n general, o variabil este cunoscut prin intermediul unui
identificator, asociat datei reprezentate, numit identificator de variabil.
Informaie ce nsoete o categorie sintactic. Toate atributele unei
categorii sintactice formeaz informaia semantic asociat categoriei,
determinndu-i "nelesul". Atributele sunt asociate unui nume de
obicei prin declaratii, dar pot rezulta i din context. Momentul la care
se face aceast asociere ntre o categorie sintactic i un atribut al su,
4

Asociere
Operaie

Societate
informaional
Software
Document
Baza de Date
Model

Flux
informaional
Cod

se numete momentul legrii.

Reprezint legturile dintre tabele (n baza de date).
(Intrare-ieire) activitate care se desfoar n sistemul de intrare-ieire
la execuia unei comenzi. Operaia de intrare-iesire desemneaz aciuni
executate de canalul de intrare-ieire, unitatea de legtur i
echipamentul periferic desemnate la iniierea programului de canal, din
care face parte comanda.
Se nate ntr-un mediu n care numrul celor care folosesc tehnologii
informaionale depete o mrime critic.
Ansamblul programelor ce asigur funcionarea calculatoarelor sau a
unor aplicaii informatice.
Formular care urmeaz a fi completat de ctre utilizator, pentru
introducerea direct a datelor folosind tehnici de recunoatere a
formelor.
Este un ansamblu structurat de date legate funcional ntre ele. Baza de
date este gestionat de programe numite sisteme de gestiune a bazelor
de date.
Descriere formal a unui sistem de ateptare prin specificarea modului
de intrare a cererilor n sistem, a structurii irurilor de ateptare i
unitii de servire precum i a disciplinelor de servire utilizate n staii.
Un astfel de model nu poate descrie dect aproximativ un sistem real
datorit caracterului pur aleator al intrrii cererilor n sistem i absenei
unui aparat matematic care s descrie complet procesul de servire.
Reprezint drumul parcurs de o informaie din momentul apariiei ei i
pn cnd, pe baza cunoaterii activitii ce a dat natere informaiei, se
declaneaz un nou proces economic.
Codul reprezint o succesiune finit de caractere (cifre i litere) prin
care este caracterizat un atribut dintr-o colectie de date.

n continuare, vor fi prezentate studiile de caz ale modelelor alese de studenii care au
lucrat la aceste implementri (numele, facultatea i titlul fiecrui studiu de caz).

Andronic Ionu, Soare Ana Facultatea de tiina i Tehnologia Informaiei

SOCIETATE COMERCIAL DE FABRICARE DE MOBILIER

Societatea comercial SOLMOB S.R.L. a fost nfiinat n anul 1995 i i are sediul n
comuna Pantelimon, Str.Livezilor, nr.22, iar punctul de lucru este n oraul Pantelimon,
Str. Sf. Pantelimon, nr. 6.
Principalul obiect de activitate este producia, n care sunt incluse:
o Fabricare de mobilier pentru dormitoare, sufragerii, buctrii, grdini etc
o Finisarea mobilierului, cum ar fi: vopsirea, lcuirea i tapiarea, cu excepia
scaunelor i banchetelor.
n cadrul acestei societi, atunci cnd se dorete s se obin un nou produs, la nivelul
seciei de producie se ntocmete aa-numita reet a produsului, un act nefiscal n care
sunt menionate toate materiile prime, materialele necesare, precum i cantitile acestora.
Aceste informaii sunt transmise n gestiunea societii care verific rezistena acelor
materii prime i materiale necesare, iar pentru fiecare se va elibera un bon de consum.
Astfel, se va descrca din gestiune, fiind aprobat transferul ctre secia de producie care
le va recepiona.
Secia de producie va trece la consumul materiilor prime i materialelor, conform reetei.
Astfel, se va obine produsul dorit care, n prealabil, a fost finisat.
Imediat obinut produsul, secia de producie elibereaz ctre gestiune nota de predare,
astfel fiind nregistrat n gestiune noul produs finit.

Diagrama cazurilor de utilizare:

Diagrama claselor:

Diagrama de secvene:

Diagrama strilor pentru clasa materii prime si materiale:

Astfel, n diagrama claselor se vor aduga urmtoarele metode:

1. n starea INSCRISE IN RETETA s-au adaugat metodele:Cantitate pt fiecare
materie i material n parte care se va trece printre operaiile clasei Reet; Adaug
materii i materiale, terge materii i materiale i Modific cantitatea materiilor i
materialelor, care se vor aminti printre metodele clasei Materii prime i materiale.
2. n starea ELIBERATE PE BONUL DE CONSUM se vor aduga urmtoarele
metode: Cantitatea materiilor de pe fiecare bon, Cantitatea materialelor de pe fiecare
bon i Preul fiecrei materii i fiecrui material de pe fiecare bon, clasei Bon
consum.
3. n starea REGASITE IN PRODUS se vor aduga operaiile Cantitatea de materii
regsite n produs i Cantitatea materialelor regsite n produs, clasei Produse
finite.

10

Diagrama claselor dup realizarea diagramei de stare a clasei Materii prime i

materiale:

11

Diagrama de colaborare:

1.
2.
3.
4.

se verific existena cantitilor de materii i materiale din gestiune

materiile i materialele sunt descrcate din gestiune(BC)
se elibereaz BC n funcie de denumirile materiilor i materialelor
gestiunea aprob transferarea materiilor i materialelor ctre secia de producie

Astfel, n diagrama claselor se vor aduga urmtoarele atribute i operaii:

specific den materii i materiale la clasa Bon consum

12

cant de materii i materiale eliberate pe BC la clasa Materii prime i

materiale, operaie care este generat de atributul care face legtura cu clasa
Bon consum, i anume: uBonconsum- variabila identificator
verific existena cant materii i nreg BC n funcie de cant materiilor
existente la clasa Gestiune, precum i variabilele identificator: vcantmaterii
pentru a se putea utiliza informaiile din clasa Materii prime i materiale i
vBonconsum pentru a se folosi de datele din clasa Bon consum.
Diagrama claselor dup ce s-au trecut i informaiile din diagrama de
colaborare:

13

Diagrama de activiti:

NU

DA

14

M.C.D.

1,1
1,n

intocmeste

1,n
inregistreaza
1,1

1,1

1,n

1,n
MateriimatRetet

verifica
1,n
1,n
Materiimat BC
1,n

1,n

1,n

elibereaza

Prod finite NP

1,n

15

1,1

M.L.D.
Regula 1:
Rsectia de productie=(Nrsectie, Administrator, Zone de lucru,
Rreteta=(Nrreteta,
RMateriiprimesi materiale=(Codmat, Codmateriale, Denmat,
Cantmaterii, Cantmateriale, Pret,
Rgestiune=(Codgestiune,
Rbonconsum=(Nrbc, Databc, Cantbc, Pretbc,
Rnotapredare=(Nrnp, Datanp, Cantnp, Pretnp,
Rprodusefinite=(Codprodus, Denprodus, Cantprodus, Pretprodus,

Denmateriale

Um,

Denmateriale

Um,

Regula 2:
Rsectia de productie=(Nrsectie, Administrator, Zone de lucru)
Rreteta=(Nrreteta, Nrsectie, Codgest)
RMateriiprimesi materiale=(Codmat, Codmateriale, Denmat,
Cantmaterii, Cantmateriale, Pret)
Rgestiune=(Codgestiune)
Rbonconsum=(Nrbc, Databc, Cantbc, Pretbc, Codgest)
Rnotapredare=(Nrnp, Datanp, Cantnp, Pretnp, Nrsectie)
Rprodusefinite=(Codprodus, Denprodus, Cantprodus, Pretprodus)
Regula 3:
Rproduseobtinute=(Nrnp, Codprod)
Rmateriimat Reteta=(Nrreteta, Codmaterii,Codmateriale)
RmateriimatBC= (Nrbon,Codmaterii,Codmateriale)

16

Epistatu Ion Facultatea de tiina i Tehnologia Informaiei

PREZENTAREA UNUI CAZ CONCRET DE ACTIVITATE COMERCIAL.
FABRIC DE CONFECII TEXTILE

n cadrul unei fabrici de confecii textile, activitatea este structurat pe compartimente.

ncepnd cu depozitul de materiale, continund cu sala de croit, linia de fabricaie i
sfrind cu depozitul de produse finite, materialele trec prin diferite stadii de execuie
ajungnd n final produse finite.
n cazul prezentat clientul emite comanda ctre fabric asigurnd totodat i toate
materialele necesare executrii ei (aa numitul sistem LOHN).
Depozitul de materiale recepioneaz materialele din care debiteaz slii de croit
necesarul de materile principale (stof, cptuseal, furnituri).
Sala de croit croiete materialele principale transformndu-le n repere croite pe care le
transmite apoi liniei de fabricaie.
Linia de fabricaie primete materiale auxiliare (a, nasturi, embleme) cu ajutorul crora
transform prin asamblare reperele croite primite de la sala de croit, n produse finite.
Dup ambalare, produsele finite sunt stocate n depozitul de produse finite de unde se
face livrarea lor ctre client mpreun cu materialele rmase.
Dup expedierea mrfii se emite factura ctre client.
Activitatea sistemului informatic al societii descrise mai sus este realizat din
ansamblul format de datele de intrare (iniiale i intermediare), actele normative folosite,
precum i de procedeele de prelucrare a datelor.
Date de intrare:
Tranzacii externe :
nume client,
numr order,
model,
tip material,
cod material,
cantitate material,
dat producie,
dat livrare,
dat recepie material,
17

size (mrime corporala, msura ce reflect conformaia corpului),

cantitate specificat (cantitatea specificat pentru fiecare size n parte).

Tranzactii interne :
cantitate croit,
cantitate livrat,
cantitate (total) specificat,
cantitate (total) croit,
cantitate (total) livrat,
valoare factur materiale,
valoare factur manoper,
valoare factur produs,
valoare penaliti.
Acte normative:
proforma order,
tabel dimensional,
schi model,
factur materiale recepionate,
factur execuie produs finit,
legislaia vamal n vigoare,
contractul ncheiat de conducerea fabricii cu clientul.
Procedee de prelucrare a datelor:
Recepionarea i transmiterea documentelor n format electronic,
Editarea i listarea datelor,
Vizualizarea i consultarea datelor.

18

O reprezentare succint, iniial i nestandardizat a sistemului informatic ar putea fi

urmtoarea:

Procesul se desfoar astfel:

1) Societatea de confecii recepioneaz actele normative ce conin datele de intrare,
2) Se face prelucrarea datelor de intrare coninute n actele normative. Sub aspectul
prelucrare date regsim operaiile de recepie material, lansare comand, croire,
debitare material, execuie n fabricaie, livrare, facturare, etc.
Descrierea cazurilor de utilizare:
1) Denumirea sau titlul: Procesarea unei comenzi de produse de confecii,
2) Scop: Realizarea i livrarea de produse finite,

19

3) Actori: Client, Depozit materiale, Sala de croit, Linia de fabricaie, Depozit

produse finite,
4) Punct iniial: Clientul emite comanda i livreaz materialele,
5) Punct final: Depozitul de produse finite livreaz clientului produsele finite
mpreuna cu materialele rmase dupa procesarea comenzii,
6) Descriere derulare la nivelul celui mai semnificativ scenariu:
Clientul emite comanda,
Clientul furnizeaz materialele,
Depozitul de materiale recepioneaz materialele,
Depozitul de materiale emite materialele principale slii de croit,
Sala de croit primete materialele principale, realizeaz repere croite i le
debiteaz pe linia de fabricaie,
Linia de fabricaie primete reperele croite de la sala de croit precum i
materialele auxiliare de la depozitul de materiale asamblndu-le n
produse finite pe care apoi le ambaleaz i le nmagazineaz n depozitul
de produse finite,
Depozitul de produse finite livreaz produsele finite clientului mpreun
cu materialele rmase dup procesarea comenzii,
Se emite factura pentru produsele livrate ctre client.
7) Rezultat msurabil: Comanda este onorat prin livrarea produselor finite.
Unified Modeling Language reprezint o nou metod de analiz i poiectare orientate
obiect aparut ca urmare a introducerii standardizrii. U.M.L. nu reprezint o metod n
sine ci este mai mult un instrument, o notaie grafic ce acoper majoritatea diagramelor
necesare reprezentrii ciclului de via al unui sistem informatic.
n continuare sunt prezentate cteva diagrame UML specifice sistemului informatic
tematic ales:
1) Diagrama cazurilor de utilizare,
2) Diagrama claselor,
3) Diagrama de secvene,
4) Diagrama schimbrilor de stare.
Diagrama cazurilor de utilizare :
n diagrama cazurilor de utilizare sunt inclui actorii i cazurile de utilizare iniiate de
acetia. Cazurile de utilizare descriu interaciunile poteniale dintre actori i sistemul
informatic. Actorii sunt elemente ale sistemului care genereaz evenimente.
20

proiect
Emite comanda
Livreaza materiale
Client

<<include>>
<<extend>>

Receptioneaza materiale
<<include>>

Returneaza materiale ramase

<<include>>

Debiteaza materiale auxiliare

Debiteaza materiale principale
<<include>>
Depozit_materiale

<<include>>
Primeste materiale auxiliare
Primeste materiale principale
Sala_de_croit
Alimenteaza repere croite

Primeste repere croite

<<include>>

Livreaza produse finite

<<extend>>

Depozit_produse_finite
Ambaleaza

Rezerva capacitate productie

<<extend>>

Depoziteaza produse
Factureaza

n diagrama de mai sus, cazurile de utilizare se observ c pot avea ntre ele diferite
relaii:
- relaia de extensie:
1) Returneaza materiale rmase este o extindere a cazului Recepioneaz materiale,
2) Depoziteaz produse este o extindere a cazului Ambaleaz care este la rndul su
o extindere a cazului Livreaz produse finite,
- relaia de incluziune:
3) cazul Alimenteaz repere croite este inclus n Primete repere croite,

21

Linie_de_fabricatie

4) Cazul Primete materiale principale este inclus n Debiteaz materiale principale

care este inclus n Receptioneaz materiale care la rndul su este inclus n Livreaz
materiale.
Diagrama claselor:
Diagrama claselor este reprezentarea relaional a claselor unui sistem.
Clasele corespund semantic entitilor din sistemul real. Ele sunt constituite din grupuri
de obiecte cu atribute, operaii i relaii comune.
Client

NumeClient : char
ValoareM anopera : real
ValoareM ateriale : real
AfiseazaClient()
Livreaza()
Factureaza()
Penalitati()
Furnizeaza
*Emite

Comanda

Livreaza

Materiale receptionate

NrOrder : integer
M odel : string
NumeClient : char
DataProductie : string
DataLivrare : string
CantitateSpecificata : integer
Size : char
TotalCantitateSpecificata : integer

TipM aterial : char

CantitateM aterial : real
CodM aterial : string

Lanseaza
*

AfiseazaM aterial()
ReturneazaRest()
ElibereazaNecesar()
Receptioneaza materiale()
Debiteaza
*

CalculeazaNecesar()
ProcesareOrder()
Repere croite

NumarSerie : integer
NrOrder : integer
Size : char
CantitateCroita : integer
TotalCantitateCroita : integer
TimbreazaProdus()
ImperecheazaProdus()
PrimesteM aterialePrincipale()
Alimenteaza

Planifica
*

Produse finite

Produse livrate
NrOrder : integer
Size : char
CantitateLivrata : integer
TotalCantitateLivrata : integer

BarcodProdus : undefined
CantitateFinita : integer
TotalCantitateFinita : integer
Size : char

*
Ambaleaza

InregistreazaBarcod()
AlimenteazaRepereCroite()
AlimenteazaM aterialeAuxiliare()
RezervaCapacitateProductie()

Ambaleaza()
ReturneazaM ateriale()

22

Diagrama de secvene:
Diagrama de secvene reprezint interaciunile dintre obiecte din punct de vedere
temporal, ilustrnd ordinea cronologic a interaciunilor dintre ele pentru scenarii ale unui
singur caz de utilizare.
n diagrama de secvene sunt reprezentate numai obiectele ale cror clase au fost descrise
i ntre care exist relaii n diagrama claselor. Obiectele relaioneaz prin mesaje, iar
mesajele au coresponden cu operaiile claselor din care fac parte obiectele.

Client:

Comanda:

M ateriale receptionate:

Repere croite:

Produse finite:

Produse livrate:

Proceseaza

Rezerva capacitate productie

Receptioneaza materiale

Alimenteaza materiale principale

Alimenteaza repere croite

Alimenteaza materiale auxiliare

Ambaleaza

Returneaza materiale

Livreaza

Factureaza

n
diagrama de secvene se observ c din punct de vedere temporal,
secvena Livreaz precede dou secvene anterioare : Ambaleaz i Returneaz
materiale, ntruct una dintre condiiile contractuale prevede livrarea produselor
mpreun cu restul materialelor rmase.

23

Diagrama schimbrilor de stare :

Diagrama de stare descrie comportamentul obiectelor unei singure clase evideniind
dinamica atributelor i legturilor sale cu alte obiecte din sistem.
Astfel, conform diagramei de stare de mai jos, comanda poate fi lansat numai dac sunt
satisfcute simultan urmtoarele condiii: exist capacitate de producie i exist
materiale recepionate.

cancel[receptioneaza materiale = 0]
start

Comanda lansata

start[rezerva capacitate productie > 0]

M ateriale receptionate
Do/ receptioneaza materiale

quit

cancel[rezerva capacitate productie = 0]

start[receptioneaza materiale >0]

24

Produse finite
Do/ rezerva capacitate productie

Ionescu Maria-Nancy Facultatea de tiine Economice

ACORDAREA UNUI CREDIT DE CTRE ING ROMANIA

Acordarea unui credit bancar (de un anumit tip) pentru o persoan fizic indiferent dac
deine sau nu cont la banca ING.
Descrierea companiei :
ING Romania face parte din ING Group, unul dintre cele mai puternice grupuri
financiare din lume. De-a lungul anilor, ING i-a cstigat i pe piaa romneasc reputaia
de grup financiar ce ofer cele mai complexe produse i servicii pentru o palet larg de
clieni : corporaii, instituii i persoane fizice.
ING Romania ofer :
-produse bancare pentru companii
-produse bancare pentru persoane fizice
-asigurri de viaa i pensii
ING Group desfoar o gam variat de operaiuni n Romnia, oferind un pachet
complet de servicii.
Credite oferite pentru persoanele fizice :
1. ExtraROL - linie de credit
2. ING Personal credit
3. Credit ipotecar
4. Credit de nevoi personale cu ipotec
Documente necesare creditului :
-cerere de credit
-copia actului de identitate
-acord de consultare Biroul de Credite
-adeverin de salariu sau alte documente doveditoare ale venitului (n funcie de
tipul de activitate pe care l desfoar persoana fizic)
-acte de proprietate
DENUMIRE : acordarea unui credit bancar
ACTORII
: consultantul de credite i persoana fizic
SCOPUL
: stabilirea acordrii sau nu a creditului
INCEPUT : persoana fizic solicit creditul
consultantul de credite solicit documentaia i verific
FINAL
: acordarea creditului

25

Activitati efectuate :
- persoana fizic solicit un credit ipotecar
- consultantul de credite cere documentaia
- dac persoana fizic are deja cont deschis la Banca ING, se verific informaia
existent ; daca nu, datele personale ale persoanei fizice sunt introduse n baza de
date spre deschiderea unui cont
- sistemul calculeaz posibilitatea acordrii creditului ipotecar
- dup analiza datelor, creditul ipotecar este permis
- persoana fizica primete ntiinarea i se ncheie un contract de credit
REZULTATUL : creditul ipotecar este acordat
Diagrama Use Case:
Persoana fizica

Consultantul
de credit
Solicita
creditul

Cere
documentatia

Depune
documentele
Calculeaza
posibilitatea
acordarii
creditului

Primeste
informatia

Informeaza
persoana
fizica
Incheie
contractul

Diagrama claselor :
Clasele sunt : PersoanaFizica
Cerere
Credite
SituatieFinanciara
ContractCredite
26

CPersoanaFizica

CCerere

CCredite

DenPersFiz : String
CodPersFiz : Integer
Localitate : String
Telefon : Integer
vidCerere : Boolean
AfiseazaDenumire()
StergePersFiz()
AdaugaPersFiz()
AfiseazaPersFizCerrere()

NrCerere : Integer
DataCerere : String
ValCerere : Cerere
Stare : String
AfiseazaCerere()
AdaugaCerere()
StergeCerere()
AfiseazaValCerere()
IncarcaDataCerere()
AfiseazaAprobat()
AfiseazaAprobatPartial()
SeteazaStare()
AfiseazaDataAprobarii()
ListaSume()

CodCredit : Integer
TipCredit : Sting
DenCredit : Sting
AfiseazaTipCredit()
AdaugaDenCredit()
StergeTipCredit()

CSituatieFinanciara
CodPersFiz : Integer
VenitAnual : Real
ActeProprietate : String

CContractCredite

AdaugaSitFin()
StergeSitFin()
ModificaSitFin()

ModificaContract()
StergeContract()
AdaugaContract()
AfiseazaContract()
IncarcaContractCredite()

NrContract : Integer
DataContract : String
SumaAcordata : Real
Dobanda : Real
Penalitati: Real

Diagrama de secvene:
PersoanaFizica:
PersoanaFizica

Credit:

ConsultantCredite:

Solicita
Cere documentatia
Depune documentele

27

Contract:

Calculeaza posibilitatea
acordarii creditului
Informeaza persoanele fizice
Incheie

Diagrama de colaborare:

PersoanaFizica :

1 : realizeaza o

3 : se acorda

Cerere:

2 : se aproba
Credite:

Pentru urmrirea solicitrii i acordrii creditului se construiete urmtoarea diagram de

colaborare :

CPersoanaFizica
DenPersFiz
Vid : Cerere
AfiseazaPersFizCerere()

CCerere
NrCerere
DataCerere
ValCerere
AfiseazaValCerere()

28

CCredite
CodCredit
TipCredit
DenCredit
StergeTipCredit()
AdaugaDenCredit()

Pentru afiarea persoanelor fizice i numrul cererii corespunztoare n clasa

CPersoanaFizica, la atribute este necesar o variabil identificator Cerere.
Daa n clasa CCerere am efectuat operaia AfiseazaValCerere() , ne ntoarcem n
DIAGRAMA CLASELOR i adugm aceast operaie.
Diagrama de stare (pentru clasa CERERE) :
Acceptat

Sosit
DO:consul PersFiz
verific PersFiz

trimitere

nregistrat
DO:ncarc data PersFiz
ncarc Cerere

[SumaSitFin < ValCerere]

Aprobare
Parial

n curs de aprobare
DO: CalcValCerere
Afieaz aprobat parial

[SumaSitFin=ValCerere]
Aprobat
DO: Lista Sume
Afieaz data
Seteaz Stare

Pentru a putea efectua n clasa Cerere operaia SeteazaStare, este necesar declararea
unui atribut Stare de tip String .
Dac n diagrama de stri ncrcm datele din cerere, ne ntoarcem n diagrama
claselor i trecem aceast operaie IncarcaDateCerere() .
Analog
pentru
AfiseazaAprobat(),
AfiseazaAprobatPartial(),
AfiseazaDataAprobarii(), ListaSume() => dac n diagrama de stri am facut aceste
operaii, ne ntoarcem n diagrama claselor i le adugm n clasa CCerere.

29

Diagrama de activiti:
-se completeaza descrierea cazurilor de utilizare
SE SOLICITA CREDITUL

SE SOLICITA DOCUMENTATIA

SE ADUCE DOCUMENTATIA

SE INTRODUC DATELE IN SISTEM

SE VERIFICA DATELE
DA

NU

SE APROBA
ACORDAREA
CREDITULUI

SE REFUZA ACORDAREA
CREDITULUI

SE INTOCMESTE
CONTRACTUL DE
CREDITE

NU SE REALIZEAZA
CONTRACTUL DE
CREDITE

30

Liscan Maria Facultatea de tiine Economice

Sistem informatic pentru urmrirea activitii ntr-o agenie imobiliar
Descrierea activitii ageniei imobiliare
Agenia imobiliar CASA TA SRL este o agenie nou apruta pe piaa romneasc,
singurul domeniu de activitate al firmei fiind cel al tranzaciilor imobiliare.
(apartamente/ultra/semi/central, case i vile, birouri, spaii comerciale, industriale,
terenuri) pe baza unui contract de intermediere.
n activitatea sa curent, agenia imobiliar ntreine relaii cu clienii si , care
acioneaz asupra ofertelor i cererilor .
Sistemul informatic al ageniei imobiliare este conceput i pus la dispoziia utilizatorilor
(agenilor imobiliari) pentru a transfera aceste evenimente n mulimi de mai multe
operaii. De acum totul devine mai simplu. Aplicaia permite utilizarea aceleiai baze de
date centralizate pentru gestiunea ofertelor i cererilor prezentate. Sistemul va fi generat
dupa ce se va ncepe efectiv introducerea ofertelor clienilor.
Principalele activiti ale ageniei imobiliare:
Descrierea activitilor principale ale ageniei are n vedere stabilirea obiectivelor
sistemului informatic n raport cu particularitile activitii unei agenii imobiliare,
cerinele conducerii acesteia i prioritile stabilite prin legislaia imobiliar.
Principalele servicii oferite de agenie sunt:
intermedieri n vederea vnzrii, cumprrii sau nchirierii de proprieti imobiliare;
consultan n domeniul pieei imobiliare;
evalurii imobiliare;
Clienii care constituie piaa int a ageniei sunt clienii care au nevoie de servicii de
nchiriere relativ ieftine i nu solicit servicii extra, cumprri de apartamente, case i
vile, spaii comerciale i de birouri, depozit, hale de producie, terenuri intravilane i
extravilane.
Activitatea de urmrire a ageniei
Se refer la materializarea tranzaciilor care au loc n cadrul ageniei i asigurarea
colaborrilor la nivelul gestiunilor ofertelor i cererilor, al gestiunilor contractelor i al
editrilor de rapoarte i documentaii.
Activitatea de gestiune a utilizatorilor
Grupurile de utilizatori ai sistemului informatic sunt organizate dup urmtoarele criterii:
- personalul ageniei;

31

- cei cu drepturi de acces preferenial (agenii imobiliari i administratorul de

sistem);
- dup durata existenei (grupuri temporare, create la apariia unor drepturi de
care pot beneficia numai anumite persoane, i permanente);
Activitatea de gestionare a ofertelor i cererilor
Activitatea de constituire i actualizare a ofertelor i cererilor ageniei se desfoar ntre
clientul ageniei persoan fizic sau juridic i agentul imobilar.
Aceast activitate este format din urmtoarele operaii complexe :
Solicitarea unei oferte de ctre client
Selectare ofert
Definitivarea contractului
Procesarea facturii i efectuarea plii
n scopul derulrii acestor operaii complexe se desfoar urmtoarele fluxuri
informaionale :
Activitatea 1:
Clientul ii expune dorina agentului imobiliar; aceasta conine datele generale pentru ca
agentul s poat identifica mai uor oferta.
Activitatea 2 :
Clientul acceseaz baza de date adugnd cererea, iar n cazul n care este disponibil ceva
apropiat de dorina clientului se selecteaza si i se prezint aceasta.
Activitatea 3:
n cazul n care se finalizeaz aciunea cu un contract, se emite n final factura ctre client.
Activitatea de gestiune a contractelor
Activitatea 1:
Agentul imobiliar poate aduga un contract, poate realiza modificri i are drept de anulare
a acestuia. El mai poate face cutri n baza de date.
Activitatea 2 :
A doua activitate surprinde situaia n care deja contractul este finalizat; se realizeaz
vizualizarea i tiprirea acestuia.
Definirea obiectivelor sistemului informatic al ageniei imobiliare
Obiectivele sistemului informatic presupun abordarea i rezolvarea informatic a unor
probleme cu caracter sintetic, ntr-o manier sistematic. Aceste obiective au caracteristici
generale i specifice ce depind de cadrul legislativ-normativ, dotarea cu tehnic de calcul,
cu maini pentru deplasare i cerinele dezvoltrii economice, imediate i de perspectiv,

32

ale ageniei respective. Programul informatic este complex, propriu i nglobeaz att
activitile realizate de agent ct i de administratorul de sistem. n acest fel faciliteaz
folosirea programului prin controlul asupra drepturilor i obligaiilor utilizatorilor.
Diagrama cazurilor de utilizare:
Cazul principal de utilizare:
Diagrama ofer o imagine de ansamblu asupra principalelor activiti desfurate n cadrul
unei instituii. Actorul a fost intitulat agent imobiliar i este cel care beneficiaz i n
acelai timp efectueaz toate activitile prezente n diagram. Fiecare dintre aciunile
reprezentate n diagrama general a cazurilor de utilizare vor fi reluate i prezentate pe larg,
punndu-se n eviden toate activitile care le compun.
Diagrama cazului de utilizare pricipal:
Actorul agent imobiliar se ocup de primirea clienilor, cutarea n baza de date i
ntocmirea contractelor. n aceast situaie interaciunea actorului cu sistemul const n
consultarea disponibilului de apartamente, garsoniere, terenuri prin verificarea opiunilor
menionate de client. Astfel, actorul ofer un rspuns promt, fr a pierde timpul cu notarea
informaiilor i cu verificrile.

Cazurile iniiale: acceptare/respingere, cerere i documentare privind detaliile rezervrii,

devin acum un singur caz.
Practic, singura responsabilitate a personalului este aceea de a furniza aplicaiei datele
rezervrii. Nu este necesar completarea vreunui formular ci doar cutarea datelor.
Actualizarea disponibilului este automat.

33

Diagrame detaliate ale cazurilor de utilizare:

Diagrama de gestiune a utilizatorilor:

34

Diagrama de gestiune a ofertelor si cererilor:

Adugarea unei oferte sau a unei cereri se face cu ajutorul calculatorului, n diverse
situaii putnd interveni necesitatea modificrii datelor unui contract, n caz de neplat, de
exemplu, anulndu-se contractul. Nu se completeaz niciun formular de anulare a
contractului, acest lucru fcndu-se automat: agentul (actorul) face modificarea
respectiv sau anularea, iar disponibilul ageniei se actualizeaz automat.

35

Diagrama claselor :

Diagrama de secvene:
Diagramele de secven dezvolt n mod natural scenariile cazurilor de utilizare. Acestea
transform evenimentele identificate n scenariile cazurilor de utiliare, ntr-o reprezentare
grafic a utilizrilor sistemului de ctre un actor. Fiecare eveniment are ca rezultat un
mesaj trimis unui obiect cu perspectiva c acel obiect va realiza o operaie.
Diagrama de secven descrie cronologic interaciunea obiectelor, identificnd mesajele
schimbate ntre obiecte ca rspuns la un eveniment, precum i secvena mesajelor. Este o
vizualizare a intercomunicrii claselor pentru un anumit scenariu al cazurilor de utilizare.

36

a ) Diagrama de secven pentru Logare:

b ) Diagrama de secven pentru Stabilire disponibil:

37

c ) Diagrama de secven pentru ncheiere contract:

38

d ) Diagrama de secven pentru nregistrare client:

39

e ) Diagrama de secven pentru Emitere factur:

Diagrama de stare:
Diagramele de stare realizate identific evenimentele care fac tranziia unui obiect dintr-o
stare n alta. Aceste diagrame descriu toate operaiile i atributele unei clase n timpul
unui eveniment. Diagrama identific stimulii care declaneaz aciunea. Ea include
numele strii oricrei variabile n timp ce obiectul este n funciune, precum i
evenimentul care declaneaz tranziia la o nou stare.

40

Diagrama de stare a unui imobil :

Diagrama de activiti:
Diagramele de activitate permit o mai bun nelegere a operaiilor, n special a celor
foarte complexe. Prin intermediul acestor diagrame sunt evideniate detaliile din cadrul
unor operaii ale claselor.
Aceste diagrame sunt reprezentate sub forma unui tip de stare care specific activitatea
unei anumite clase. Diferena const n faptul c un grafic de stare reprezint ntregul
obiect, n timp ce o diagram de activitate reprezint n mod tipic doar o operaie n
cadrul unui obiect .

41

Cererea
clientului

Verificare
cerere client

Nu sunt
ndeplinite
cerinele

Sunt
ndeplinite
cerinele

Completare
formular

Completare
contract

Nu se fac
modificri

Apar
modificri

Completare,
modificare,
tergere
contract
42

Se
respinge
clientul

MODELUL CONCEPTUAL AL SISTEMULUI INFORMATIC PRIVIND

ACTIVITATEA UNEI AGENII IMOBILIARE

Clienti :
Nume si
prenume :
CNP :
Adresa :
Telefon :
E-mail :

1,n

1,1
Contract :
Nr contract :
Data contact :
Tip imobil :
Mod de plata :

Incheie
1,n

Imobil contactat
Tip imobilc:
Pret contactat:

1,n
Emit

1,n

1,1
Document de plata :
Nr document :
Data document :
Tip document :
Suma platita :

Factura
platita

1,n
Imobil:
Tip imobil:
Pret imobil :
Descriere imobil:
Stare imobil:
Mentiuni:

1,n
Conform

1,1
1,1

1,n

Facturi :
Nr factura :
Data factura:
Stare factura :
1,n

43

Imobil facturat:
Tip imobilf:
Pret facturat:

MODELUL LOGIC DE DATE AL SISTEMULUL INFORMATIC

PRIVIND ACTIVITATEA UNEI AGENII IMOBILIARE
Pentru trecerea de la modelul conceptual de date (MCD) la modelul logic de date (MLD)
se aplic regulile lui CODD:
1 . Pentru fiecare entitate din MCD se definete n MLD o relaie (schema de
relaie) ce conine atributele entitii .
2 . Dac ntr-o asociere pentru o entitate cardinalitatea maximal este 1, n
MLD, tabelului corespunztor i se adaug cheia entitii cu care intr n asociere i
atributele asocierii .
3 . Dac ntr-o asociere ambele cardinaliti maximale sunt n, n MLD se
adaug o nou relaie ce conine cheile celor dou entiti, precum i atributele asocierii.
RClienti = ( Nume i prenume, CNP, Adresa, Telefon, E-mail)
RContract = ( Nr contract, Data contract, Tip imobil, Mod de plata, CNP )
RImobil = ( Tip imobil, Pret imobil, Descriere imobil, Stare imobil, mentiuni )
RFacturi = ( Nr factura, Data factura, Stare factura, Nr contract, Nr document )
RDocumentDePlata = (Nr document, Data document, Tip document, Suma platita, CNP )
RContractImobil = ( Nr contract, Tip imobil, Pret contractat )
RFacturiImobil = ( Nr factura, Tip imobil, Pret facturat )

44

MODELUL ORGANIZATIONAL DE PRELUCRARE AL SISTEMULUI

INFORMATIC PRIVIND ACTIVITATEA UNEI AGENII IMOBILIARE

Agenti :

Imobil :

Client :

Contract :

Consultare
NU

DA

Refuz
Verificare
client

Exista
Clientul ?

?
NU

DA
Adauga
client

Adauga
contract

Modifica
contract

Stergere
contract

45

Livezeanu Colda Miruna Facultatea de tiina i Tehnologia Informaiei

APLICAIE PENTRU GESTIUNEA STUDENILOR, CURSURILOR I A
FACULTILOR UNEI UNIVERSITI
n cele ce urmeaz vom prezenta o aplicaie simpl ce realizeaz gestiunea datelor
referitoare la studeni, faculti i cursuri ale unei univeriti.
Aplicaia are n componen o baz de date unde sunt pstrate toate informaiile
referitoare la studei, faculti i cursuri.
Baza de date este realizat n microsoft Access 2003 i are n componen urmtoarele
tabele:
- Cursuri pstreaz informaiile referitoare la cursuri: id-ul cursului, numele cursului
i numrul de credite aferent acestuia.
- Promovai pstreaz informaiile despre situaia scolar a studentilor, i anume daca
sunt sau nu promovai, n tabel este reinut numru matricol al studentului i string-ul
da sau respectiv nu n cmpul promovat dac studentul este au nu promovat.
- Studeni pstreaz informaiile referitoare la studeni: numrul matricol, numele i
prenumele, numrul de credite precum i grupa din care face parte studentul, anul
deducndu-se din prima cifra sa numrului grupei.
- Studeni_Cursuri este tabelul care face legatura dintre studeni i cursurile alese si
frecventate de acetia. O nregistrare a tabelului va conine urmtoarele informaii:
numarul matricol al studentului, id-ul cursului, precum i nota obinut de student
la
cursul respectiv. n cazul n care studentul nu are nota nc stabilita la cursul respectiv
cmpul nota va avea valoarea null i va putea fi completat ulterior. Fiecare student are
un numr de inregistrari in tabelul Studeni_Cursuri egal cu numrul de cursuri pe care le
frecventeaz.
- Facultate reine informaiile referitoare la facultile universitii, i anume: id-ul
faculii si numele acesteia.
- Studeni_Faculti pstrez informaiile referitoare la repartiia studentilor n
faculti, i anume numrul matricol al studentului i id-ul facultii pe care acesta o
frecventeaz. Datorit faptului ca acest tabel are cheia primar compus din ambele
cmpuri, i anume: nr_matricol i id_facultate un student poate fi nscris la mai multe
faculti.

46

Figura (1) arata relaiile dintre tabelele bazei de date. Campurile subliniate reprezint
cheile primare ale tabelelor respective

Fig.1
Aplicaia mai are n componen i o interfa grafic realizat n limbajul Java cu
ajutorul mediului de programare NetBeans 5.5 i utiliznd jdk1.6.0.
Interfaa grafic este cea care realizeaz comunicarea uoar ntre utilizator i baza de
date permitndu-i acestuia din urm sa realizeze interogrile dorite intr-un mod extrem de
simplu, prin apasarea unui singur buton.
Aplicaia are o pagin prinicipal pe care se gsete meniul de unde utilizatorul poate
selecta una aciunea dorita. Utilizatorul poate ntreprinde urmtoarele aciuni:
- Adugare cursuri - aceast opiune permite utilizatorului sa adauge n baza de date
cursurile nou aparute, utilizatorul nu trebuie decat sa completeze informaiile aferente pe
fromularul din pagin.
- Adugare facultate - aceast opiune permite utilizatorului sa adauge n baza de date
una sau mai multe facultti nou nfiinate.
- Adugare promovai - aceasta opiune realizeaz adugarea studenilor i a situaiei
colare a acestora n tabelul Promovai. Acest lucru se realizeaz foarte uor, utilizatorul
trebuie sa
introduc doar numrul matricol al studentului toate calculele n privina
numrului de credite i a situaie colare fiind efectuate de ctre aplicaie.
- Adugare studeni - este opiunea care permite introducerea studenilor nou
nmatriculai n baza de date.
- Adugare studeni - cursuri : adauga, n baza de date, informaiile referitoare la
cursurile frecventate de fiecare student n parte.

47

- Adugare studeni - facultate : adauga, n baza de date, informaiile legate de

facultatea sau facultile, dup caz, la care este nscris fiecare student n parte.
Pentru realizarea acestei aplicaii am folosit diagramele UML care permit studierea
modului de lucru al aplicaiei din mai multe puncte de vedere. Am utiliyat trei tipuri de
diagram UML, i anume urmtoare
Diagrama Use Case:
Diagrama USE CASE sau diagrama cazurilor de utilizare mi-a permis sa identific actorii
care intervin n sistem precum si aciunile pe care acestia le efectueaz sau sunt efectuate
asupra lor.
Astfel am identificat trei actori:
- Student: n cazul studentului apar urmtoarele cazuri de utilizare:
- Este nscris la o facultate
- Are cursuri
- Primete note
- Facultate: apar cazurile de utilizare urmtoare:
- Are studeni nscrii
- Are cursuri
- Curs: cu un singur caz de utilizare:
-Are numr de credite.
n
figura
(2)
este
prezentat diagrama USE
CASE.

Fig.2

48

Diagrama Claselor:
Diagrama CLASELOR, care este singura dintre diagramele UML care este
implementabil.Aceasta diagram mi-a pemis sa identific clasele pe care urma s le
implementez n sistem, cmpurile i metodele acestora.
n cadrul acestei aplicaii apare un fapt ciudat, clasa Studeni_Facultti nu are nici
cmpuri i nici metode proprii, aceste lucru datorndu-se faptului ca aplicaia este o
aplicaie cu baza de date iar clasa respectiv nu face dect sa-ne permit s facem
legatura ntre clasele Studeni i Faculti.
n figura (3) prezentm diagrama de clase a aplicaiei.

Fig.3
Diagrama de Secvene:
Ultima diagrama UML pe care am folosit-o la realizarea proiectului este Diagrama de
SECVENE care ilustreaz interaciunile dintre obiecte din punct de vedere temporal.
Este ntocmit pentru scenarii ale unui caz de utilizare i arat obiectele i interaciunile
dintre ele de-a lungul unui scenariu.
n diagrama de secvene apar doar obiectele ale cror clase sunt reprezentate n diagrama
claselor i ntre care au fost definite relaii. Mesajele corespund operaiilor prin care
obiectele comunic. Reprezint apeluri ale operaiilor descrise la niveul claselor. Pentru
fiecare mesaj, n clasa obiectului destinatar, trebuie sa existe o operaie corespunztoare,
reacia obiectului la mesajul primit.

49

Aceast diagram ne-a ajutat sa punem n eviden mesajele dintre obiecte.

n figura (4) prezentm diagrama de SECVENE a aplicaiei:

Fig.4

50

Lupoaie Andra-Elena Facultatea de tiina i Tehnologia Informaiei

Visual Paradigm for UML1 - MODEL DE FUNCIONARE A LIFTULUI
Visual Paradigm for UML este o
unealt vizual UML CASE care este
de mare ajutor n construirea
aplicaiilor ntr-un mod mult mai rapid,
mai bun i mai ieftin. Cu ajutorul
acestui instrument se pot construi toate
modelele de diagrame de modelare
oferindu-se i facilitatea de generare de
cod n diferite limbaje de programare.
n special n cursul fazelor de analiz
i dezvoltare a procesului, Visual
Paradigm for UML v va ajuta s obinei un produs de calitate superioar.
Pentru a arta funcionalitatea acestui instrument, am avut n vedere un model cunoscut
de toat lumea, i anume FUNCIONAREA LIFTULUI. n continuare voi prezenta
enunul acestui model i paii ce trebuie urmai pentru construirea diagramelor n Visual
Paradigm for UML.
Enun: Model de funcionare a liftului:
-Pasagerul apas butonul de la un etaj;
-Sistemul liftului detecteaz butonul apsat, precum i etajul de la care a fost apelat
-Uile se deschid
-Pasageru intr i apas butonul etajului dorit
-Uile se nchid
-Liftul se mut la etajul
cerut
-Uile se deschid
-Pasagerul iese
-Uile se nchid

www.visual-paradigm.com

51

Pentru acest model, voi construi n Visual Paradigm ase diagrame UML. Pentru a

construi o nou diagram se alege din meniul File -> New Diagram -> UML Diagrams .
Diagrama Use Case:
De regul, diagrama Use Case se compune prima. Aceasta descrie relaiile i
dependinele dintre diferite grupuri de cazuri de utilizare i actori participani la proces.

52

Diagrama Class:
Diagrama de clase arat diferite clase din care este compus sistemul. Diagrama arat
operaiile (metodele) i atributele (variabile) claselor precum i structura static a claselor
sistemului, adic ce clase se cunosc sau ce clase fac parte din altele. ns diagrama de
clase nu prezint apeluri de metode ntre ele.

Diagrama State:

53

Diagramele State arat diferite stri ale obiectului, pe parcursul existenei lui, precum i
cauzele schimbrii strilor. Diagramele State prezint obiectele ca automate finite care
pot fi ntr-una din cteva stri finite. Strile pot fi schimbate de un numr finit de cauze.
Aceast diagram a fost construit pentru clasa lift. Se observ c toate aciunile din
aceast diagram apar n diagram class ca operaii. De fapt, motivul pentru care a fost
construit aceast diagram, ca toate diagramele prezentate n continuare, este
completarea diagramei class.
Diagrama Sequence:
Diagrama Sequence arat comunicarea dintre diferite obiecte (apelurile diferitelor
metode) unde factorul timp joac rolul principal. Diagrame Sequence indic ordinea
apariiei i durata comunicrii ntre obiecte.
n timpul construirii diagramei de secvene s-a observat necesitatea crerii unei noi clase,
numit Pasager, care va fi adugat n diagrama class.

54

Astfel, n urma modificrilor aduse, diagrama class va arta astfel:

Diagrama Activity:
Diagramele Activity descriu ordinea aciunilor sistemului cu ajutorul diferitelor Activity.
Aceasta este o form special a diagramei State, ns conine n principal aciuni.
Diagramele Activity sunt asemntoare cu diagramele procedurale de Flux, cu deosebirea
c toate aciunile sunt legate de un obiect.
Aceast diagram a fost cel mai mult utilizat la scrierea codului n Java, programul
urmnd exact ordinea aciunilor din programul principal: public static void
main(String[] args).

55

Diagrama Collaboration:

Diagramele Collaboration arat interaciunea dintre obiecte ntr-o situaie concret. Spre
deosebire de diagramele Sequence care pun accent pe interaciunea exprimat n timp,
diagramele Collaboration arat legturile logice ntre obiecte.
A se observa c aciunile din aceast diagram completeaz la randul lor operaiile din
diagrama class.
Creare cod surs:
Dup ce modelul este creat, este interesant de vzut cum poate fi creat codul surs al
modelului. Diagramele ajut mai mult la nelegerea structurii modelului dect la crearea
codului surs. Totui, Visual Paradigm for UML v ajut s exportai clasele create n
unul din limbajele C++, Java sau PHP. Visual Paradigm creaz mostrele de clase care v
permit s scriei clasele implementnd funcionalitile dorite. Pentru asta, ducei cursorul
la Tools -> Instant Generator i de aici alegei limbajul dorit.

56

O s apar urmtoarea fereastr n care va trebui s completai cerinele i pe urm vei

avea clasele gata generate.

57

S deschidem unul din fiierele generate i s vedem cum arat poriunea de cod
generat, care bineneles trebuie completat de programator.
CLASA C_BUTON:

58

Pentru acest model am implementat i programul n Java. Prin cteva printscreen-uri o s

vedem cum anume.

Cod sursa (exemplu implementare Java):

package lift;
import java.util.*;
import java.lang.*;
class C_USA {
private boolean _inchisa = true;
private static C_MOTOR _controleaza=new
C_MOTOR();
public void deschide() throws Exception {
_inchisa=false;
System.out.println("Usa s-a deschis!");
}
public void inchide() throws Exception {
_inchisa=true;
System.out.println("Usa s-a inchis!");
}
}
class C_LIFT {
private boolean _directie=true;
private int _etaj=0;
private static C_MOTOR _controleaza=new C_MOTOR();
59

public void ajunge() throws Exception {

_etaj=_controleaza.contor_etaj();
System.out.println("Liftul a ajuns la etajul "+_etaj);
}
public void opreste() throws Exception {
_directie=false;//Liftul nu mai este in miscare
}
public boolean statut() throws Exception {
return _directie;
}
}
class C_BUTON {
private boolean _iluminat=false;
private C_MOTOR _comunica=new C_MOTOR();
public void ilumineaza() throws Exception{
_iluminat=true;
System.out.println("Butonul de la etajul "+_comunica.contor_etaj()+" s-a
aprins!");
}
public void opreste_lumina() throws Exception {
_iluminat=false;
System.out.println("Butonul de la etajul "+_comunica.contor_etaj()+" s-a
stins!");
}
public void statut() throws Exception {
System.out.println("Motorul functioneaza!");
}
public void apasa() throws Exception {
ilumineaza();
}
}
class Pasager{
private boolean _inauntru=false;
private boolean _intra=false;
public boolean in_afara(boolean p_inauntru){
_inauntru=p_inauntru;
return _inauntru;
}
public boolean inauntru(){
if (_inauntru==false)
System.out.println("Pasagerul este afara!");
else
System.out.println("Pasagerul este inauntru!");
return _inauntru;
}
public boolean intra(){

60

if (_inauntru==false)
System.out.println("Pasagerul intra!");
else
System.out.println("Pasagerul iese!");
return _inauntru;
}
}
public class C_MOTOR {
private static int _contor_etaj; //etajul la care se afla
pasagerul
private static int _pozitie; //etajul la care se afla liftul
inainte de a-l chema pasagerul
private static boolean _directie;
private static C_LIFT _controleaza=new C_LIFT();
private static C_USA _unnamed_C_USA_=new
C_USA();
private static C_BUTON _comunica=new
C_BUTON();
public static void usa_deschisa(){
try {
_unnamed_C_USA_.deschide();
}
catch(Exception e){};
}
public static void usa_inchisa(){
try {
_unnamed_C_USA_.inchide();
}
catch(Exception e){};
}
public static boolean directie() {
if (_contor_etaj>_pozitie)
_directie=true; //liftul urca
else
_directie=false; //liftul coboara
return _directie;
}
public static int contor_etaj() throws Exception {
return _contor_etaj;
}
public static int pozitie() throws Exception {
return _pozitie;
}
public void apeleaza() throws Exception {
_comunica.apasa();
_pozitie=_contor_etaj;

61

}
public void muta() throws Exception {
_controleaza.ajunge();
_comunica.opreste_lumina();
_controleaza.opreste();
}
public static void main(String[] args){
C_MOTOR motor=new C_MOTOR();
Pasager pasager=new Pasager();
System.out.println("Dati etajul la care sunteti!(Etajul la care se afla pasagerul)");
Scanner in=new Scanner(System.in);
motor._contor_etaj=in.nextInt();
System.out.println("Pasagerul este inauntru=true sau afara=false?");
Scanner sc=new Scanner(System.in);
pasager.in_afara(sc.nextBoolean());
try {
motor.apeleaza();}
catch (Exception e){};
if (pasager.inauntru()==false)
{ try {
motor.muta();
motor.usa_deschisa();
if (pasager.intra()==false) //Pasagerul intra
{ motor.usa_inchisa();
System.out.println("Dati etajul la care pasagerul doreste sa ajunga!");
Scanner et=new Scanner(System.in);
motor._contor_etaj=et.nextInt();
motor.apeleaza();
motor.muta();
motor.usa_deschisa();
pasager.in_afara(true);
pasager.intra();
motor.usa_inchisa();
}
else //Pasagerul iese
{motor.usa_inchisa();
pasager.inauntru();
}
}
catch (Exception e) {};
}
else
try
{
motor.usa_inchisa();
motor.muta();

62

motor.usa_deschisa();
pasager.in_afara(true);
pasager.intra();
motor.usa_inchisa();
}
catch (Exception e) {};
}
}

Testare:
Orice produs informatic trebuie testat nainte de punerea pe pia. Exist diferite
metode de testare a unui produs informatic. Pentru modelul de mai sus, se va utiliza
Criteriul de parcurgere a drumurilor din graful de control o reea care cuprinde
structurile de control ale programului.
Mai jos este o variant de construire a grafului de control pentru programul care
implementeaz modelul discutat. Testarea se face pentru poriunea de cod din programul
principal, cea colorat cu albastru mai sus.

63

in= ; sc= ;

motor.apeleaza()

pasager.inauntru()=false

pasager.inauntru()=true

motor.usa_inchisa()
motor.muta()

motor.muta()
motor.usa_deschisa()

i
pasager.intra ()=false

motor.usa_inchisa(); et=

pasager.intra()=true

motor.usa_deschisa()

pasager.in_afara()

motor.usa_inchisa()

pasager.intra()
motor.apeleaza()

pasager.inautru()

motor.usa_inchisa()

motor.muta()

motor.usa_deschisa()

pasager.in_afara(true)

pasager.intra()

motor.usa_inchisa()

64

n continuare, se vor lua n considerare 3 jocuri de test i se va arta aplicarea criteriului

de testare pentru acestea.
1.

et=4 ; sc=false
Se observ c se parcurge ramura then a instruciunii if.

2.

et=4 ; sc=true
Se observ c se parcurge ramura else a instruciunii if.

65

3.

et=9 ; sc=false

66

Marinescu Angela Nicoleta Facultatea de tiina i Tehnologia Informaiei

SCHEMA CREDITRII UNEI BNCI
Descrierea activitii:
1. Denumire: finanarea de credite
2. Scop: creditarea clienilor persoane fizice i juridice
3. Actori: clientul, banca
4. Punct iniial: depunere cerere clieni
5. Punct final: aprobare de credite
6. Derularea activitii:
-

Clientul depune cererea de credit la banc;

Inspectorul de credite verific dosarul clientului, dac acesta i-a depus actele
necesare analizei i actualizeaz baza de date dac vine un client nou;

Se ntocmete dosarul de analiz a situaiei financiare a clientului;

Face calculul coeficientului de ndatorare a creditului;

Aprob sau nu cererea de credit;

Informaiile finale cu privire la acordarea de credit sau nu ajung la client.

7. Rezultatul msurabil: cererile clienilor i contractele de credit sunt numerotate

cantitativ (automat de
ctre un program folosit de banc).

67

Diagrama cazurilor de utilizare:

Descrierea activitii se regsete n diagrama de utilizare.

Explicaii:
-

clientul vine i depune la banc documentele respective pentru o cerere de credit;

inspectorul de credite verific informaiile cu privire la documente i poate

actualiza baza de date a clienilor;

inspectorul de credite face calculul coeficientului pe baza documentelor depuse,

analizeaz suma cerut de ctre client;

directorul de credite din cadrul bncii aprob sau nu cererea de credite a clientului
n funcie de rezultatele calculate.

n final, informaiile cu privire la cerere ajung la clieni.

68

Diagrama claselor i obiectelor:

n diagrama claselor i obiectelor se prezint urmtoarele elemente:

- n clasa CLIENTI sunt prezentate caracteristicile clienilor;
- n clasa CREDITE sunt introduse toate felurile de credite i anume: credite pentru
nevoi personale cu i fr ipotec, credite de consum, credite ipotecare, credite auto,
credite pentru turism, credite pentru tratamente medicale, credite imobiliare, i se poate
calcula pentru fiecare fel de credit dobnda aferent pe un an sau 6 luni;
- n clasa CERERI CLIENTI se trec: denumirea creditului, perioada de creditare (adic
n ci ani poate clientul s achite suma contractat) i suma cerut ;
- clasa CONTRACTE CREDITE reflect creditele aprobate de ctre banc i include
numrul i data semnat de ctre client n contract, precum i suma contractat cu
dobnda respectiv i termenul de plat al finanrii creditului;
- clasa SITUATIE FINANCIARA este utilizat pentru verificarea documentelor i
extragerea unor informaii legate de client necesare pentru finanarea cu credite, i
anume: cifra de afaceri sau venitul pe cap de locuitor pentru persoane fizice precum i
69

profitul, dividendele pentru persoane juridice i alte datorii de plat. Tot aici se va calcula
i coeficienul de ndatorare al clientului i se analizeaz suma cerut deoarece banca
trebuie s ii planifice n aa fel finanarea creditelor nct s nu se ajung la lichidarea ei.
NOT: vom aduga variabila identificator n clasa SITUATIE FINANCIARA pentru
denumire client i cod client i pentru denumire credit din clasa CONTRACTE
CREDITE.

Diagrama de secvene:

Contracte
cereri

Cereri
clienti
Clienti
Depunere cerere

Credite

Situatie
financiara

Cerere credit

Situatie financiara actualizata

Calcul coeficient
Aprobare contracte credit
Acordare credit

Observaie: mesajele primite n diagrama de secvene se regsesc n diagrama claselor i

obiectelor la clasele destinate.

70

Diagrama de stare:
a) Pentru client:

71

b) Pentru cerere credit:

Observaie: Metodele i atributele adugate noi n diagrama de stare se regsesc i n

diagrama claselor i obiectelor.
Aceast diagram de stare s-a construit pentru a se vedea ce stri tranziteaz un client
atunci cnd depune o cerere de credit la banc, precum i o cerere de credit, dup cum se
vede n modelul de mai sus.

72

Diagrama de activiti:

Se primeste cererea client

Se analizeaza suma ceruta

Se inregisteraza cererea de credit

Se refuza cererea de credit

Se acorda creditul

Not: ? : suma cerut de client poate fi aprobat i acordat sau nu, n funcie de
prioritile bncii. Se ine seama foarte mult de suma contractat, de felul creditului i
mai ales de situaia financiar a clientului. n urma calculelor fcute de ctre inspectorul
de credite senior pentru clientul respective, se acord creditul ( coeficientul de
rambursare a creditului).
Diagrama de colaborare:
Diagrama de colaborare este realizat tocmai pentru a se observa colaborrile n timpul
depunerii, analizei i aprobrii unei cereri de credit i anume:
-

clientul vine la banc i depune cererea de credit;

cererea se verific de ctre banc;
creditele includ analiza cererii;
se analizeaz coeficientul din situaia financiar a clientului;
analiza este fcua pentru a se observa dac clientul este capabil s returneze
banii;

73

se acord sau nu creditul n funcie de analiza fcut;

clientul ramburseaz creditul.

Clienti:

Cerere client:

Den client

Nr.cerere

1:depunere
cerere

Cod client

Data cerere

Tel client

Credite:
2:se verifica
cererea de
credit

Denumire
credit

Adresa cl

Denumire cerere
credit

Afisare den cl

Suma ceruta

Dobanda
aferenta

Afisare cod cl

Total cereri

Afisare fel credit

Total sume cerute

Afisare
dob/6luni
Afisare dob/an

Situatie
financiara:

Contracte
credite:
Nr.contract
Data
contract

Cod credit

3:se
analizeaza
situatia
financiara a cl

VIDen cl
5:se acorda
creditul

VIden credit

VICod cl
Vn sau
Ca/pers
Calcul coeficient

Suma
contractata

Total Vn/familie

Afiseaza cl
6:rambursare
credit

Total credite
aprobate

74

4:nu se
acorda

Modelul conceputual de date (MCD):

CLIENTI

CREDITE

Den client
Cod client
Tel client

Denumire
credit
Cod credit

Adresa cl

Dobanda
aferenta

1,n

CERERI
CLIENTI
1,n

contine

Nr.cerere
Data cerere
Denumire cerere
credit
Perioada cerere
credit

depune

1,1

ClContracte

1,n

1,n

Suma ceruta

1,n

Suma
perioada

SITUATIE
FINANCIARA

CONTRACTE
CREDITE

VIDenumire cl

1,n

VICod cl

aproba

Nr.contract

1,1

Data contract

Vn sau Ca/pers

VIden credit

profit

Suma contractata

dividende

dobanda

Alte credite de
plata

Termen plata

1,n

analiza

Modelul logic de date (MLD):

75

1,1

Regula 1:
RClienti = (DenClient, CodClient, AdresaClient, TelClient, Nr.cerere )
RSituatieFinanciara =( VIdenClient, VIcodClient, VnsauCa/pers, profit, dividende,
AlteSumeDePlata,
Nr.contract )
RCredite = (DenCredit, CodCredit, DobandaAferenta, Nr.Cerere)
RCereriClienti = ( nr.cerere, DataCerere, DenCredit, PrioadaCrereCredit, SumaCeruta)
CodClient ,CodCredit)
RContracteCredite = ( nr.Contract, DataContract, VIdencredit, SumaContractata,
dobanda, TermenPlata)

Regula2:
RClientiContracteCredite = (DenClient, CodClient,Nr.Contract)

Mihailescu Marius Iulian Facultatea de tiina i Tehnologia Informaiei

76

SISTEM DE NREGISTRARE AL STUDENILOR UNEI UNIVERSITI

Proiectul Sistem de nregistrare al Studenilor unei Universitti ii propune creearea
unei aplicaii ce servete att studen ilor ct i profesorilor n planificarea examenelor i
nregistrarea pentru acestea.
Etapele ce au stat la baza implementrii sistemului sunt :
1.Tabel de evenimente
2.Diagrama UseCase
3.Diagrama de clase
4.Crearea bazei de date
5.Implementarea programului propriu-zis
Sistemul are la baz patru evenimente fundamentale pentru orice sistem proiectat n acest
scop i anume :
Departamentul furnizeaz orarul claselor
Timpul de producere al orarului
nregistrarea studentului pentru clas
Timpul de producere al listelor pentru clase
Toate aceste evenimente precum i alte detalii legate de ele sunt descrise n tabelul de
evenimente ce urmeaz:
Tabel de evenimente pentru Sistem de nregistrare al Studenilor unei Universitti
Actorul ce
Actorul
Numr
Descriere
Datele de
furnizeaz
Datele de
ce primete
eveniment
eveniment
intrare
datele de
ieire
informa iile
intrare
de ieire
1.
Departamentul Orarul
Departament
submite
claselor
orarul claselor
2.
Timpul de
Orarul
Student
producere al
universitaii Departament
orarului
pe clase
Profesor
3.
nregistrarea
Cerere
Student
Lista
Student
studentului
nregistrare
studen ilor
pentru clasa
pe clase
4.
Timpul de
Lista clase
Profesor
producere a
listelor pentru
clase
Versiune :
Modificri :

Data :

77

Tabelul de evenimente constituie una dintre etapele fundamentele ale implementrii

sistemului, cu el clarificnd exact ce date de intrare avem, cine le furnizeaz, ce
informaii ies din sistem i cine le primete.Tabelul de evenimente a fost construit pe
baza analizei evenimentelor aa cum ilustreaz imaginea de mai jos.

Diagrama Use Case:

Diagrama de cazuri (UseCase) pentru acest proiect reprezint aciunile ce au loc cnd
actorul folosete sistemul pentru a completa un proces.Diagrama arat ntr-un mod grafic
sistemul n relaie cu actorii i mediul nconjurtor.

Diagrama de clase:

78

Diagrama de clase sub form grafic urmarete aceleai convenii ca cele ale unui model
de domeniu.Cu ajutorul ei sa identificat relaiile dintre clase, tipul atributelor etc ,n final
acest lucru permitnd lejeritatea implementrii sistemului.

Paraschiv Georgiana, Silistri Nurgian, erban Camelia - Facultatea de tiine Economice

79

MODEL DE NTREPRINDERE PRODUCTOARE DE PRODUSE DE

PAPETRIE
ntreprinderea este productoare de produse de papetrie.
Vnzrile se pot realiza pe baz de:
1) Comand primit de la clieni. Comanda este analizat verificndu-se stocul
existent i analizndu-se clientul. Se verific dac exist contract ncheiat cu
clientul, n caz contrar, clientul este introdus n baza de date. n urma analizei,
comanda este acceptat sau respins. Dac se aprob comanda, se ntocmete
factura i se livreaz marfa. Dac nu se accept comanda, clientul este informat.
2) Vnzare n magazinele proprii. Produsele finite sunt date spre vnzare pe baza
procesului verbal de predare. n magazinele proprii, vnzarea se face pe baza
bonului fiscal, iar n cazul n care clientul solicit factura, aceasta este ntocmit.

Diagrame UML (Limbaj standard de modelare)

Diagramele UML sunt mijloacele de reprezentare i vizualizare a elementelor de
modelare. Diagramele sunt:
1.
2.
3.
4.
5.
6.

Diagrama cazurilor de utilizare

Diagrama claselor
Diagrama de secvene
Diagrama de colaborare
Diagrama de stri
Diagrama de activiti

Diagrama cazurilor de utilizare:

Aceast diagram descrie comportamentul sistemului n activitatea de vnzare.

80

Vanzari
<<include>>

Transmitere comanda

Receptie comanda

Analiza stoc
<<include>>
<<include>>

Analiza comanda

Analiza client

<<extend>>
Acceptare comanda

Introducere client BD
Intocmire factura

Firma
Client

Livrare marfa
<<include>>
Respingere comanda

Informare client

Intocmire proces verbal

<<include>>
Inctomire bon fiscal

Primire bon fiscal

<<extend>>

<<include>>

Primire factura

Intocmire factura

Diagrama claselor:
Aceast diagram evideniaz structura static a sistemului de activitate a ntreprinderii.
S-a optat pentru realizarea a dou diagrame de clas pentru o mai bun evideniere a celor
dou modaliti de vnzare din cadrul firmei:

81

Vnzri pe baz de comand

Mf in gestiune

C lienti

C omanda

Codclient : integer
Denclient : string
Adresa : string

Codm arfa : integer

Nr com anda : integer

Denm arfa : string

Datacom anda : string

Cantm arfa : integer

Pretm arfa : integer

Afiseaza data unei com enzi()

Adauga com anda()

Telefon : integer
Afiseaza clientii din Bucuresti()

Calculeaza val m arfii()

Adauga o m f noua()

Mf comandate
C odmfC : integer
Denm fC : string
Cantm fC : integer

Documente

vMf in gestiune : undefined

Nrdoc : integer

Verifica stoc existent in gestiune()

Datadoc : string
Afise aza data unui docum ent ()

Mf facturata
C ontracte

Codm arfaF : integer

Facturi

Denm arfaF : string

Term en : integer

vMf facturata : undefined

Adauga un nou contract()

Afiseaza val fara TVA a unei facturi()

Prelungeste term enul unui contract()

Calcule aza TVA pe o factura()

Cantm arfaF : integer

Pretm arfaF : integer
vFacturi : undefined

Afiseaza valoarea totala a unei facturi()

Caluleaza val m arfii de pe o factura()

Vnzri n magazinele proprii

C lienti
Codclient : integer
Denclient : string
Adresa : string
Telefon : integer
Adauga client nou()

Magazin

Bon fiscal

Codm agazin : integer

Denm agazin : string

Nrbon : integer
Databon : string
vMfvanduta : undefined

Adresa : string
vBonfiscal : undefined

Afiseaza valorea m arfii pe un bon()

Afiseaza bonuri em ise()

Mf vanduta
Codm fV : integer
Denm fV : string
Cantm fV : integer
Pretm fV : integer
Afiseaza valoarea m arfii vandute()

82

Diagrama de secvene:
Aceast diagram ilustreaz interaciunile dintre obiecte din punct de vedere temporal.
Este ntocmit pentru scenarii ale unui caz de utilizare artnd obiectele i interaciunile
dintre ele de-a lungul unui scenariu.
Scenariul prezentat n aceast diagram este: Firma primete comanda care este
analizat.n urma analizei, firma ntocmete factura care este apoi trimis la client.

Firma:

Comanda:

Facturi:

Clienti:

primeste

analizeaza
intocmeste

se trimit

Diagrama de colaborare:
n diagram se specific mesajele schimbate ntre obiecte de-a lungul legturilor.

Se adaug n diagrama claselor urmtoarele atribute i metode:

- n clasa Clienti se adaug metoda: Adauga client()
- n clasa Comanda se adaug atributul VClienti care permite apelarea
atributelor din clasa Clienti, i metodele Afiseaza datele despre clientul X() i
Afiseaza clientul la comanda nr..()
- n clasa Mf in gestiune se adaug metoda Lista mf cu stoc zero()

83

Diagrama de stri:
Aceast diagram modeleaz ciclul de via al unei singure clase evideniind
evenimentele care determin schimbrile de stare.
Au fost realizate dou diagrame de stare pentru evidenierea celor dou modaliti de
vnzare din cadrul firmei.
a) n cazul vnzrilor pe baz de comand, diagrama de stare s-a realizat pentru
marfa care are uratoarele stari:n gestiune, comandat, facturata.

Se adaug n diagrama claselor urmtoarele metode:

- n clasa Mf in gestiune : Adauga mf noua
- n clasa Comanda : Verifica comanda
- n clasa Mf facturata : Afiseaza marfuri facturate
b) n cazul vnzrilor n magazine, diagrama de stare s-a realizat pentru marfa care
are urmtoarele stari: n gestiune, n magazine, vndut.
Marfa
In gestiune

In magazin

Do: Ada uga m a rfa noua ()

Do: Afise a za adre sa m a ga zin()

Vanduta
Do: Afise aza lista m a rfii va ndute ()

Se adaug n diagrama claselor urmtoarele metode:

- n clasa Mf in gestiune : Adauga mf noua
- n clasa Magazin : Afiseaza adresa magazin
- n clasa Mf vanduta : Afiseaza lista marfii vandute
Diagrama de activiti:
Aceast diagram descrie comportamentul sistemului introducnd elemente de
implementare. Ataat unui caz de utilizare i detaliaz aciunile i procesele
corespunztoare.

84

Se primeste comanda
Se verifica daca marfa e in stoc
DA

NU

Se verifica daca exista contract

incheiat cu clientul
DA

NU
Se adauga in BD

Se accepta comanda

Se refuza comanda

Se intocmeste factura
Se livreaza marfa

Se informeaza clientul

MCD = Modelul conceptual de date:

MCD rezult dintr-o activitate de modelare complex i subiectiv. Pentru definirea
entitilor i a relaiilor, metoda Merise propune dou tehnici:
- modelarea prin atribute
- modelarea prin entiti
MLD = Modelul logic de date:
Pentru trecerea de la MCD la MLD se aplic regulile lui Codd:
1)
Pentru fiecare entitate din MCD se definete n MLD o schem de relaie
ce conine atributele entitii.
RClienti = (Codclient, Denclient, Adresa, Telefon)
RContract = (Nrcontract, Datacontract, Termen)
85

RComanda = (Nrcomanda, Datacomanda)

RMarfuri = (Codmf, Denmf, Cantmf, Pretmf)
RFacturi = (Nrfact, Datafact)
RBonfiscal = (Nrbon, Databon)
RMagazine = (Codmag, Denmag, Adresa)
2)

Dac ntr-o asociere pentru o entitate, cardinalitatea maximal este 1, n

MLD, tabelului corespunztor i se adaug cheia entitii cu care intr n
asociere i atributele asocierii.

RContract = (Nrcontract, Datacontract, Termen,Codclient)

RComanda = (Nrcomanda, Datacomanda, Codclient)
RFacturi = (Nrfact, Datafact, Nrcomanda)
RBonfiscal = (Nrbon, Databon, Codclient,Codmag)
3) Dac ntr-o asociere, ambele cardinaliti maximale sunt n, n MLD se adaug
o nou relaie ce conine cheile celor dou entiti i atributele asocierii.
RComandaMarfuri = (Nrcomanda, Codmf, Cant cmd)
RFacturiMarfuri = (Nrfact, Codmf, Cantmf F, Pretmf F)
RBonfiscalMarfuri = (Nrbon, Codmf, Cantmf V, Pretmf V)
n continuare au fost definite tabelele, rezultate din modelul logic de date, n sistemul de
gestiune a bazelor de date relaionale, Acess.

Informaii rezultate la ieire sunt:

1. Afiai comenzile pentru un client

86

2.
3.
4.
5.

Valoarea total a vnzrilor

Valoarea vnzrilor pe magazine
Stocul final pe fiecare marf
Valoarea total a facturilor emise

1.

Afiai comenzile pentru un client interogarea:

Rezultatul interogrii este:

2. Valoarea total a vnzrilor - interogarea:

Rezultatul interogrii este:

3. Valoarea vnzrilor pe magazine interogarea:

87

Rezultatul interogrii este:

4. Stocul final pe fiecare marf interogarea:

Rezultatul interogrii este:

5. Valoarea total a facturilor emise interogarea:

88

Rezultatul interogrii este:

Pentru a calcula valoarea total a facturilor emise s-a realizat un raport.

89

Petra Andreea, Nicolescu Roberta Facultatea de tiine Economice

SOCIETATE COMERCIAL DE ACHIZIIONARE DE FLORI I PLANTE
ORNAMENTALE

Societatea comercial AZALEEA SRL achiziioneaz flori i plante ornamentale ct i

materiale auxiliare.
Societatea are urmtoarele componente:
1. departamentul ADMINISTRATIE
2. departamentul VANZARE
3. departamentul APROVIZIONARE
4. departamentul LIVRARE
Administraia ncheie contracte cu Furnizorii. Pe baza contractului furnizorii emit facturi,
livreaz marfa i materialele auxiliare.
n cazul n care marfa primit nu corespunde din punct de vedere calitativ clauzelor
contractuale, administraia ii rezerv dreptul de a refuza lotul respectiv de marf.
Vnzarea se face att la punctul de lucru (en-detail), ct i prin contract semnat cu
clienii. Pentru un contract cu o valoare mai mare de 200 RON se vor face reduceri
comerciale de 2%. Marfa se poate vinde ca atare sau se poate prelucra sub forma
buchetelor sau aranjamentelor florale.
n urma semnrii contractelor cu clienii, marfa va fi livrat acestora, se va emite factura,
apoi se va nregistra documentul de ncasare.
Diagrama cazurilor de utilizare:

90

Diagrama claselor - Furnizori

n aceast diagram, clasa Administratie are rolul de gestionar al sistemului cu

ajutorul caruia se pot afla numeroase inflormaii prin introducerea unor variabile
identificatori din celelalte clase n funcie de nevoile rezultate din operaiile executate.

91

Diagrama claselor Clienti

92

Diagrama de secvene:

Diagrama de secvene este realizat doar pentru o parte din activitatea firmei, i anume:
aprovizionarea.
Operaii precum: Incarca factura primita, Incarca contract, Incarca Document Plata
se vor observa adugate n diagrama claselor furnizori .

93

Diagrama de colaborare:

n aceast diagram de colaborare am evideniat relaia existent ntre clasele: Furnizori

Contracte Furnizori Facturi Primite.
Astfel, prin introducerea unei variabile identificator V. Ident C.Facturi Primite - n
clasa Contracte Furnizori vom putea obine informaii despre contractele cu facturi
(Metoda: Afiseaza Contract cu factura). Identic se va proceda i n cazul clasei Furnizori
(V.Ident C.Facturi Primite) pentru a obine informaii despre furnizorii cu facturi.
De asemenea, aceste informaii se mai pot obine i cu ajutorul clasei Administratie,
aa cum este exemplificat n diagrama claselor furnizori, simplificnd sistemul. Acest
lucru este posibil prin introducerea variabilelor identificator corespunztoare, i a
operaiilor necesare.

94

Diagrama de stare:
Diagrama de stare

n aceast diagram sunt evideniate strile prin care trece marfa Cod marfa .

95

Diagrama de activiti:

n timpul activitii, n cazul n care marfa primit de la furnizori nu corespunde calitativ,

poate fi returnat, iar n cazul contractelor semnate cu clienii, ce depesc suma de 200
RON, se va acorda o reducere de 2%.

96

Modelul Conceptual de Date:

Modelul Logic de Date:

Regula 1:
Pentru fiecare entitate din MCD se definete n MLD o relaie ce conine atributele
entitii.
Regula 2:
Dac ntr-o asociere pentru o entitate cardinalitatea maximal este 1, n MLD, tabelului
corespunztor i se adaug cheia entitii cu care intr n asociere i atributele asocierii.
Regula 3:

97

Dac ntr-o asociere ambele cardinaliti maximale sunt n, n MLD se adaug o nou
relaie ce conine cheile celor dou entiti i atributele asocierii.
RFurnizori = ( CodFurnizor, CIF, AdresaFz, TelefonFZ
RContracte = (NrContract , Data Contract , TermenContract, CodFurnizor)
RMarfa = (CodMarfa, DenumireMarfa, PretMarfa)
RFacturiPrimite = (NrFactura, DataFactura, NrContract, NrDocument,TipDocument)
RDocumentePlata = (NrDocument, TipDocument, DataDocument, SumaPlata,
CodFurnizor)
RContracteMarfa = (NrContract, CodMarfa, CantitateContractata, PretContractat)
RFacturiPrimiteMarfa = ( NrFactura, CodMarfa, CantitateFacturata)

98