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 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 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

Subsistem Decizie

Dat

Procedur

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 1,n inregistreaza 1,1 intocmeste 1,1 1,n MateriimatRetet verifica 1,n 1,n Materiimat BC 1,n 1,n

1,n 1,1

1,n Prod finite NP

elibereaza

1,n

15

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, 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)

Denmateriale

Um,

Denmateriale

Um,

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 <<include>> <<extend>> Returneaza materiale ramase <<include>> Debiteaza materiale auxiliare Debiteaza materiale principale <<include>> <<include>> Primeste materiale auxiliare Primeste materiale principale Sala_de_croit Alimenteaza repere croite <<include>> Primeste repere croite Depozit_materiale Receptioneaza materiale <<include>> Client

Livreaza produse finite <<extend>>

Rezerva capacitate productie

Linie_de_fabricatie

Depozit_produse_finite Ambaleaza

<<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

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 NrOrder : integer M odel : string NumeClient : char DataProductie : string DataLivrare : string CantitateSpecificata : integer Size : char TotalCantitateSpecificata : integer CalculeazaNecesar() ProcesareOrder() Repere croite NumarSerie : integer NrOrder : integer Size : char CantitateCroita : integer TotalCantitateCroita : integer TimbreazaProdus() ImperecheazaProdus() PrimesteM aterialePrincipale() Alimenteaza * * Produse finite BarcodProdus : undefined CantitateFinita : integer TotalCantitateFinita : integer Size : char InregistreazaBarcod() AlimenteazaRepereCroite() AlimenteazaM aterialeAuxiliare() RezervaCapacitateProductie() * * Materiale receptionate TipM aterial : char CantitateM aterial : real CodM aterial : string * AfiseazaM aterial() ReturneazaRest() ElibereazaNecesar() Receptioneaza materiale() Debiteaza *

Livreaza

Lanseaza

Planifica

Produse livrate NrOrder : integer Size : char CantitateLivrata : integer TotalCantitateLivrata : integer Ambaleaza() ReturneazaM ateriale() * Ambaleaza

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 quit

start[rezerva capacitate productie > 0]

M ateriale receptionate Do/ receptioneaza materiale

cancel[rezerva capacitate productie = 0]

start[receptioneaza materiale >0]

Produse finite Do/ rezerva capacitate productie

24

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 DenPersFiz : String CodPersFiz : Integer Localitate : String Telefon : Integer vidCerere : Boolean AfiseazaDenumire() StergePersFiz() AdaugaPersFiz() AfiseazaPersFizCerrere()

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

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

CSituatieFinanciara CodPersFiz : Integer VenitAnual : Real ActeProprietate : String

CContractCredite NrContract : Integer DataContract : String SumaAcordata : Real Dobanda : Real Penalitati: Real ModificaContract() StergeContract() AdaugaContract() AfiseazaContract() IncarcaContractCredite()

AdaugaSitFin() StergeSitFin() ModificaSitFin()

Diagrama de secvene: PersoanaFizica: PersoanaFizica Solicita Cere documentatia Depune documentele Credit: ConsultantCredite: Contract:

27

Calculeaza posibilitatea acordarii creditului Informeaza persoanele fizice Incheie

Diagrama de colaborare: 1 : realizeaza o

PersoanaFizica :

Cerere:

3 : se acorda Credite:

2 : se aproba

Pentru urmrirea solicitrii i acordrii creditului se construiete urmtoarea diagram de colaborare :

CPersoanaFizica DenPersFiz Vid : Cerere AfiseazaPersFizCerere()

CCerere NrCerere DataCerere ValCerere AfiseazaValCerere()

CCredite CodCredit TipCredit DenCredit StergeTipCredit() AdaugaDenCredit()

28

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 trimitere

Sosit DO:consul PersFiz verific PersFiz

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 Se respinge clientul

Sunt ndeplinite cerinele

Completare formular

Completare contract

Nu se fac modificri

Apar modificri

Completare, modificare, tergere contract 42

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 : Imobil contactat Tip imobilc: Pret contactat: 1,n 1,n Imobil: Tip imobil: Pret imobil : Descriere imobil: Stare imobil: Mentiuni: 1,n

Incheie 1,n

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

1,n Conform

Factura platita

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

Imobil facturat: Tip imobilf: Pret facturat:

43

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 Refuz DA

Verificare client Exista Clientul ?

?
NU Adauga client DA 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

i
pasager.inauntru()=true

motor.usa_inchisa() motor.muta()

motor.muta() motor.usa_deschisa()

i
pasager.intra ()=false pasager.intra()=true motor.usa_deschisa()

motor.usa_inchisa(); et=

motor.usa_inchisa()

pasager.in_afara()

pasager.intra() motor.apeleaza() pasager.inautru()

motor.muta()

motor.usa_inchisa()

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:

Cereri clienti Clienti

Depunere cerere

Contracte cereri

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:
Den client Cod client Tel client Adresa cl Afisare den cl Afisare cod cl
1:depunere cerere

Cerere client:
Nr.cerere Data cerere Denumire cerere credit Suma ceruta Total cereri Total sume cerute
2:se verifica cererea de credit

Credite:
Denumire credit Cod credit Dobanda aferenta Afisare fel credit Afisare dob/6luni Afisare dob/an
3:se analizeaza situatia financiara a cl

Contracte credite:
Nr.contract Data contract VIden credit Suma contractata Afiseaza cl Total credite aprobate
5:se acorda creditul

Situatie financiara:
VIDen cl VICod cl Vn sau Ca/pers Calcul coeficient Total Vn/familie
6:rambursare credit

4:nu se acorda

74

Modelul conceputual de date (MCD): CLIENTI

Den client Cod client Tel client Adresa cl

CREDITE
Denumire credit Cod credit Dobanda aferenta

CERERI CLIENTI
1,n

contine

1,n

Nr.cerere Data cerere Denumire cerere credit Perioada cerere credit

1,n

depune

1,1

Suma ceruta

1,n

ClContracte Suma perioada

1,n

SITUATIE FINANCIARA
VIDenumire cl VICod cl Vn sau Ca/pers profit dividende Alte credite de plata
1,n

CONTRACTE CREDITE
aproba
1,1

Nr.contract Data contract VIden credit Suma contractata dobanda Termen plata

1,n

analiza

1,1

Modelul logic de date (MLD): 75

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>> Receptie comanda Transmitere comanda

Analiza stoc <<include>> Analiza comanda <<include>> <<extend>> Acceptare comanda Analiza client

Introducere client BD Intocmire factura

Firma Livrare marfa <<include>> Respingere comanda Informare client Client

Intocmire proces verbal

<<include>> Inctomire bon fiscal <<extend>>

Primire bon fiscal <<include>> Intocmire factura Primire 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

C lienti
Codclient : integer Denclient : string Adresa : string Telefon : integer Afiseaza clientii din Bucuresti()

Mf in gestiune C omanda
Nr com anda : integer Datacom anda : string Afiseaza data unei com enzi() Adauga com anda() Codm arfa : integer Denm arfa : string Cantm arfa : integer Pretm arfa : integer Calculeaza val m arfii() Adauga o m f noua()

Mf comandate C odmfC : integer

Denm fC : string Cantm fC : integer vMf in gestiune : undefined Verifica stoc existent in gestiune()

Documente
Nrdoc : integer Datadoc : string Afise aza data unui docum ent ()

Mf facturata C ontracte
Term en : integer Adauga un nou contract() Prelungeste term enul unui contract()

Facturi
vMf facturata : undefined Afiseaza val fara TVA a unei facturi() Calcule aza TVA pe o factura() Afiseaza valoarea totala a unei facturi()

Codm arfaF : integer Denm arfaF : string Cantm arfaF : integer Pretm arfaF : integer vFacturi : undefined 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()

Bon fiscal
Nrbon : integer Databon : string vMfvanduta : undefined Afiseaza valorea m arfii pe un bon()

Magazin
Codm agazin : integer Denm agazin : string Adresa : string vBonfiscal : undefined 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: primeste

Comanda:

Facturi:

Clienti:

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
Do: Ada uga m a rfa noua ()

In magazin
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 Se verifica daca exista contract incheiat cu clientul DA NU Se adauga in BD NU

Se accepta comanda Se intocmeste factura Se livreaza marfa

Se refuza comanda

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. 1.

Valoarea total a vnzrilor Valoarea vnzrilor pe magazine Stocul final pe fiecare marf Valoarea total a facturilor emise 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