Sef Lucr. Ing. Muji Marius [626010]

Universitatea Petru Maior Târgu Mureș
Facultatea de Inginerie
Specializarea Calculatoare

PROIECT DE DIPLOMĂ
SISTEM INFORMATIC PENTRU GESTIUNEA
COMENZILOR CLIENT

Coordonator științific:
Sef Lucr. Ing. Muji Marius

Absolvent: [anonimizat] 2011

1
CUPRINS
Capitolul 1 . Introducere ………………………….. ………………………….. ………. 2
1.1 Sisteme informatice și informaționale . Noțiuni generale ………………………….. ……….. 2
1.1.1. Arhitectura sistemelor informatice ………………………….. …………………………. 3
1.1.2. Prezentarea ciclului de viață a unui sistem informatic ………………………….. . 4
1.1.3. Etapele proiectării unui sistem informatic de baze de date ……………………. 5
Capitolul 2. ………………………….. ………………………….. ………………………….. 7
2.1. Specificarea cerințelor ………………………….. ………………………….. ………………………… 7
2.2. Analiza sistemului informatic ………………………….. ………………………….. …………………….. 9
2.2.1. Analiza bazei de date relationale. Modelul entitate -relație …………………….. 9
2.2.2. Analiza aplicatiei software a sistemului informatic . Diagrama procesului de
afaceri ………………………….. ………………………….. ………………………….. …………….. 13
Capitolul 3. ………………………….. ………………………….. ………………………… 18
3.1. Proiectarea bazei de date relationale . ………………………….. ………………………….. … 18
3.2. Proiectarea aplicației software a sistemului informatic . ………………………….. ………. 23
3.2.1. Diagramei f luxurilor de date ………………………….. ………………………….. …… 24
3.2.2. Diagrama cazurilor de utilizare ………………………….. ………………………….. .. 27
3.2.3. Diagrama de activitare ………………………….. ………………………….. ………….. 33
3.2.4. Diagrama de stare a tranzițiilor ………………………….. ………………………….. . 40
3.2.5. Diagrama de secvențe ………………………….. ………………………….. ………….. 44
Capitolul 4. Implementarea sistemului informatic ……………………….. 48
4.1. Implementarea bazei de date ………………………….. ………………………….. …………………….. 48
4.1.1. Limbajul SQL ………………………….. ………………………….. ………………………. 48
4.1.2. Prezentare generală Microsoft SQL Server ………………………….. ………….. 49
4.1.3. Baze de date în SQL Server ………………………….. ………………………….. ….. 50
4.1.4. Elemente ale limbajului SQL în cadrul SQL Server ………………………….. … 51
4.2. Implementarea aplicației software a sistemului informatic . ………………………….. ….52
4.2.1. Microsoft .NET ………………………….. ………………………….. …………………….. 53
4.2.2. Limbajul C# ………………………….. ………………………….. …………………………. 54
4.2.3. Clase incluse C# ………………………….. ………………………….. ………………….. 55
4.2.4. Concluzii ………………………….. ………………………….. ………………………….. … 57
Bibliografie ………………………….. ………………………….. ……………………….. 59

2

Capitolul 1 . Introducere
1.1 Sisteme informatice și informaționale . Noțiuni generale
Sistemul informațional este alcătuit din ansamblul informațiilor interne și externe
folosite în cadrul organizației , dar și datele care au stat la baza obținerii lor , procedurile și
tehnicile de obținere și difuzare a informațiilor , împreun ă cu personalul implicat în culegerea,
transmiterea , stocarea și preluarea datelor .
Într-un sis tem informațional se pot evidenția două mari componente :
– o component ă pentru stocarea informațiilor ;
– o component ă pentru prelucrarea informațiilor;

Principalele funcții pe care un sistem informațional trebuie să le îndeplinească sunt :
 colectarea de informații de la sistemele operaționale și decizionale , dar și
informații provenite din mediul extern sistemului ;
 memorarea acestor informații și a informațiilor provenite din prelucrarea lor ;
 asigurarea accesul ui la memorie în vedere a transmiterii informațiilor stocate ;
 prelucrarea informațiilor la cererea sistemului operațion al și a sistemului de
conducere ;
Folosirea echipamentelor hardware și a produselor software pentru organizarea și
administrarea detelor și a informațiilor , adică în mare infor matizarea activității unei
organizații , definește conceptul de sistem informatic .
Un s istem informatic complex poate fi descompus în mai multe subsisteme , care la
rândul lor pot fi descompuse în aplicații destinate unor anumite categorii de utilizatori , iar
aplicații la rândul lor pot fi construite pe baza a unuia sau mai multor programe scrise în
diverse limbaje de programare ( figura 1.1) . Toate aceste sisteme , subsisteme și aplicații
informatice sunt produse informatice numite și produse software .

3

Fig. 1.1. Sistem informatic ,subsistem ,aplicatie ,program
În cadrul unui produs informatic se pot distinge două mari componente :
– programele care se ocupă cu accesarea și prelucrarea datelor din baza de date
– documentația necesară pentru utilizarea și întreținerea programelor
Pentru realizarea unui sistem informatic eficient , aceste componente trebuie realizate
prin parcurgerea unor etape bine stabilite , începând cu specificarea cerințelor produsului și
terminând cu inplementarea , testarea , exploatarea și întreținerea produsului final .
1.1.1. Arhitectura sistem elor informatic e
Arhitectura unui sis tem informatic este una complexa , astfel la proiecta rea unui astfel
de sistem trebuie avute în vedere o serie de componente importante ale arhitecturii de baza a
unui sistem informatic , de la componentele de baza , până la rețele de comunicație ,
echipamente , și produse software care ajută la buna functionare a sistemului .
Componentele de bază ale unui sistem informatic sunt [2] :
 Baza informațională a unui sistem informatic este compus ă din : datele care sunt
supuse prelucr ării în cadrul sistemului , fluxu rile informa ționale , sisteme și
nomenclatoarele de coduri .
 Baza tehnică a unui sistem informatic are ca principală componentă calculatoarele
elect ronice , calculatoare care ajut ă la culegerea , transmisia , stocarea și prelucrarea
datelor necesare funcțio nării sistemului

4
 Sistemul de programe : este alcătuit din programele utilizate pentru buna funcționare
a sistemului informatic , funcționare care trebuie să respecte cerințele și funcțiile
stabilite pentru sistem [2] .
 Baza științifică și metodologică : este constituită din totalitatea algoritmilor ,
formulelor , modelelor și tehnicilor de realizare a sitemului informatic .
 Factorul uman (resursele umane) : este una dintre cele mai importante componente
a unui sistem informatic , deoarece fară contribuția o amenilor sistemul nu ar putea
funcționa corect .

Pentru realizarea unui sistem informatic eficient și corect , trebuie avute în vedere , pe
lângă componentele de bază , și echipamentele pe care sistemul va funcționa rețelele de
comunicație , pr odusele software .

1.1.2. Prezentarea ciclului de viață a unui sistem informatic
Ciclul de viață a unui sistem informatic începe cu decizia realizării sistemului
informatic care să corespundă cel mai bine cerințelor și nevoilor utilizatorilor și se termină cu
decizia înlocuirii sistemului cu unul nou , mai performant . Sistemele informatice apar, se
dezvoltă , descresc și dispar, sau printr -un ciclu nou , se perfecționează , astf el luând nastere
noi versiuni sau chiar un nou sistem .
Există mai multe modele cu ajutorul cărora se pot dezvolta sisteme informatice :
modelul cascadă, modelul spirală , modelul prototip , model incremental . Spre exemplu
modelul i ncremental ( figura 1 .2 ) prevede parcurgerea mai multor etape ale ciclului de
viață , care se desfașoară secvențial . O îmbunătățire este aceea că oferă posibilitatea de a
livra incremental proiectul, în funcție de prioritatea incrementului .

5

Fig. 1.2. Etapele ciclului d e viață a unui sistem informatic în modelul incremental
Ciclul de viață al sistemului în acest model , începe prin stabilirea cerințelor
sistemului, atribuirea cerințelor pe incremente și stabilirea arhitecturii sistemului . După ce
aceste etape au fost p arcurse cu succes se trece la implementarea propriuzisă a sistemului ,
implementare care se face în mai multe etape . Până cănd se ajunge ca sistemul să fie
definitivat , ciclul de implemantare se reia pentru fiecare incerement în parte .
Avantajele pe ca re acest model le aduce sunt :
 Prioritățile cele mai urgente pot fi livrate primele
 Durata dintre livrări este redusă
 Feedback -ul obținut de la incrementul anterior oferă specificații pentru incrementle
următoare
 Oferă un risc scăzut de esec total al proiectului
 Incrementele cu prioritate mare tind să aibă parte de cea mai multă testare

1.1.3. Etapele proiectării unui sistem informatic de baze de date
Proiectarea unui sistem informatic presupune parcurgerea următoarelor etape :
 Planificarea bazei de date [1] : odata cu această etapă se stabilește și modul în care
etapele ciclului de viață pot fi realizate cât mai eficient .
 Definirea sistem ului [1] : se specifică scopul și limitele sistemului informatic , a
utlilizatorilor săi și a domeniilor de aplicație .

6
 Colectarea și analiza cerințelor [1] : colectarea și analiza informațiilor privind partea
de organizație care va fi susținută de către s istem și utilizarea acestor informații pentru
stabilirea cerințelor utilizatorilor privind sistemul informatic .
 Proiectarea bazei de date [1] : aici are loc procesul de creare a unui proiect pentru
baza de date , care va susține operațiile și obiectivele organizației .
 Proiectarea aplciației [1] : proiectarea interfeței utilizator și programul aplicației care
utilizează și prelucrează baza de date .
 Realizarea prototipului [1] : realizarea unui model de lucru al aplicației , care permite
proiectanților sau utilizatorilor să vizualizeze și să evalueze sistemul .
 Implementarea [1] : realizarea fizică a bazei de date și a proiectelor aplicației .
 Testarea [1] : procesul de executare a programelor aplicației , cu scopul de a găsi
erori.

7
Capitolul 2.
Specificarea cerințelor și analiza sistemului informatic.
2.1. Specificarea cerinț elor
O societate comer ciala dorește informatizar ea departamentului care se ocupă de
gestiunea și lansarea în producție a comenzilor venite din partea clienților . Sistemul
informatic va trebui să se ocupe cu gestionarea eficientă a unei baze de date care conține
comenzile clienților , dar și date legate de producție și stocul de materie primă , toate acestea
avînd ca scop final urmarirea comenzilor , dar și creșterea rezultatelor producției . Obiectul de
activitate al societații comerciale este de producere și comercializar e de radiatoare pentru
diferite mașini și unelte .
Principalele cerinte și obiective ale acestui sistem informatic sunt :
 Înregistrarea de noi comenzi venite de la clienți în baza de date .
 Odata cu înregistrarea comenzilor se doreste și stocarea unor dat e minime de
identificare și contact al clienților .
 Înregistrarea de noi furnizori de materie prima .
 Gestiunea eficienta a comenzilor inregistrate și planificarea acestora în producție în
funcție de comenzile aflate deja î n derulare și de stocul de mater ie primă .
 Gestiunea eficient ă a stocului de materie primă în funcție de comenzile aflate deja în
producție și de comenzile nou venite .
 Efectuarea de noi comenzi pentru materie prima .
 Urmarirea comenzilor lansate în producție .

Clien ții – sunt persoane fizice și juridice . Pentru amb ele categorii sistemul stochează
doar anumite date esențiale de contact și identificare : id_client , nume , prenume ( pentru
persoane fizice ) , telefon , adresa de e_mail . Acest sistem informatic fiind bazat doar pe
partea de gestiune a comenzilor , nu este necesară reținerea și altor date despre clienți , acest
lucru putînd fi gestionat de catre un alt sistem informatic care să se ocupe cu operatiuni
financiare , sistem care poate fi legat de cel descris mai sus .
Produsele – sunt stocate într -un catalog de produse , ele fiind identificate du pă un
id_produs , id unic pentru fiecare produs . Ele mai sunt insoțite de date tehnice, și specificații
pentru fiecare produs în parte .

8
Comenzile – sunt identificate după un id unic . Fiecare comandă poate să conțină mai
multe tipuri de produse cu un nu mar variat de bucăți . Pentru fiecare comandă se inregistrează
datele clientului , iar în secț iunea de detalii , se inregistrează produsele comandate și numărul
de bucăți , d ar și o estimare a datei de livrare .
Gestiunea comenzilor și planificarea în producție – se realizează de catre sistemul
informatic . Pentru planificare sunt luate în calcul comenzile aflate deja în producție , dar și
stocul de materie primă .
Gestiunea stocului de materie primă – se realizează de către sistemul informatic ,
odata cu inregistrarea unei noi comenzi . Pe baza calculelor realizate de stistemul informatic ,
acesta are facilitatea de a efectua noi comenzi de materie primă pentru a satisface nevoile
de producție .
Urmarirea comenzilor lansate în producție – se face pe baza id -ului unei comenzi ,
și are ca scop documentarea despre evoluția comenzii , dar ș i documentarea person alului din
secția de producție î n vederea realizarii obie ctivelor .
Aplicația fiind dedicată activitații interne a unei companii , utilizatorii ei sunt
utilizatori specializați în domeniul în care aplicația activează și se clasific ă astfel :
1) Operatorul de marketing : are dreptul de a adăuga noi comenzi, noi cl ienți , dar și de
a vizualiza evoluția și stadiul comenzilor existente .
2) Angajat producție : are dreptul de a vizualiza comenzile pe care trebuie să le
realizeze , fiecare secție de productie avâ nd acces doar la datele comenzilor care sunt
destinate lor . Angajatul din secția de producț ie mai are dreptul de a modifica starea
comenzii pentru secția l ui ( ex : din lansat în producț ie în execu tat ) , acest lucru
permite urmă rirea stadiului de realizare a unei comenzi .
3) Managerul : are dreptul de a vizualiza to ate comenzile l ansate , indiferent de stadiul
și de secția în care se află . Managerul mai are dreptul de a consulta stocul de
materie primă , de a înregistra sau șterge din baza de date furnizori pentru materia
primă și de a urmarii stocul de materiale și de a lansa comenzi pentru umplerea
stocului .
4) Administratorul sistemului : are toate drepturile .

9
2.2. Analiza sistemului informatic
Pe baza cerințelor și specificațiilor formulate pentru sistemul informatic
care se doreș te a fi implementat , se face analiza sistemului .
Analiza se face pe două direcț ii :
 Analiza bazei de date relaționale .
 Analiza aplicaț iei din punct de vedere al pr incipalelor procese care
se regăsesc î n ea .

2.2.1. Analiza bazei de date relationale. Modelul entitate -relație
Analiza sitemului informatic , incepe prin identificarea și analiza datelor necesare
pentru derularea activității cerute de către sistem .
Modelul entitate -relație
Modelul entitate -relație este un model conceptual care definește mulțimea de entități
și relațiile ( asocierile ) dintre ele . Principalele concepte folosite pentru construcția acestei
diagrame sunt : entitatea, legaturile, cardinalitatea, atribut .
Entitatea
Entitatea – modelează clase de obiecte concrete sau abs tracte despre care se colectează
informaț ii , are existență independentă ș i poat e fi identificată în mod unic . O entitate poate
reprezenta atât obiecte fizice precum persoane , locuri sau lucruri , dar și obiecte abstracte
precum comenzi , detalii comenzi ,etc. Reprezentare fig. 2.1.

Figu ra 2.1:Reprezentare grafică pentru Entitate
Exepmlu : un client lansează o comand ă , comanda care conține unul sau mai multe
detalii comand ă și în același timp comanda este formată din produse din catalogul de
produse . Un produs aflat în catalogul de produse dispune de mai multe detalii de produc ție ,
și în același timp este compus din mai multe tip uri de materii prime care se afl ă stocate în

10
entitatea materie prim ă . Materia prim ă deține mai multi furnizorii . Acestea sunt entităț ile
sistemului inform atic și sunt p rezentate în figura 2.2 impreună cu relațiile dintre ele .

Fig 2.2 : Schema conceptuală
Principiile de bază pentru identi ficarea și reprezentarea entităț ilor sunt :
 Nu pot exista două entități cu același nume . As tfel fiecare entitate t rebuie să fie
denumită î n mod unic .
 Reprezentarea entităților se face întotdeauna prin substantive .
 Entităț ile sistemului sunt doar acele substantive reprezentative , astfel nu orice
substantiv sau obiect di n descrierea sistemului poate să reprezinte ș i o entitate . De
exemplu , avem nevoie de denumirea mater iilor prime, dar acestea nu sunt suficiente
pentru a crea o entitate . Denumirile materiilor p rime va fi un atribut al entităț ii
Materie primă .

Relațiile ( asocierile )
Relația reprezintă o asociere între entităti . O relație este o asociere nedirecționată .
Entitățile implicate într -o anumită relație sunt participanții acesteia. Numărul de

11
participanți dintr -o anumită relație se numește gradul acesteia . Exemplu : conține este o
legatură între entit ațile Comand ă și Detalii comandă fig 2.3 .

Figura 2.3 : Reprezentarea relație
Principalele reguli de identificare și reprezentare a unei relații sunt :
 Se reprezintă prin verbe .
 Între două entiț ăti pot exista una sau mai multe relații .
 Pot să existe legături cu acela și nume , dar nu pot exista legă turi intre aceleași
entități care să aiba același nume .

Cardinalitatea
Cardinalitatea unei relații indică numărul de instante din fiecare entitate care poat e
participa la relație . Numărul indicat de c ătre cardinalitate nu va fi un numă r exact , acest a
putând lua doar valorea maximă sau minimă . Cardinalitatea un ei relații se poate afla prin
răspunsul simplu la câteva intrebări puse pe baza legă turii i ntre entităț i . Exemplu : Câte
comenzi poate lansa u n client ? ră spunsul fiind : n (un număr nelimitat) . în sens opus se pune
întrebarea : Câți c lienti poate avea o comandă ? ră spunsul fiind : 1 .
Astfel , card inalitatea unei relații poate f i de 3 feluri :1 la 1 , 1 la n și n la m
 Cardinalitatea 1 la 1 ( unu la unu ) : constă în faptul că , unei instanțe din
prima e ntitate din relație îi corespunde o singură instanță din a două entitate a
relației .
 Cardinalitatea 1 la n ( unu la multi ) : constă în faptul că , unei instanțe din
prima entitate din relației îi corespund mai multe instanțe din a două entitate
a relației .Exemplu fig. 2.4 .

Figura 2.4 : Cardinalitate 1 la n

12

 Cardinalitatea n la m ( multi la multi ) : constă în faptul că , unei in stanț e
din prima entitate din relaț ie îi corespund mai multe instanțe din a două
entitate a relației și invers , adică unei instanțe din a două entitate îi
corespund mai multe instanțe din prima entitate . Exemplu fig. 2.5 .

Figura 2.5 : Cardinalitate n la m

Atributele
Atributul este o proprietate care descrie un anumit aspect al unei entități . O entitate se
diferențiaza de alte entități printr -un ansamblu de atribute care permit descrierea precisă a
acesteia . Atributele prin care este descrisă o ent itate se aleg încât să fie relevante relativ la
domeniul de interes pe care se defineste modelul respectiv [3]. Exemplu : id_comandă și
id_produs sunt atribute ale entitatii Comanda .
Diagrama Entitate – Relație corespunzătoare bazei de date a sistemului
informatic
Entitățile sistemului, reprezentate prin dreptunghiuri , împreună cu legăturile dintre
ele, reprezentate prin arce neorientate și specificându -se cardinalitatea acestora , constituie
Diagrama Entitate -Legătură corespunzătoare bazei de date a sistemului informatic .
Principalii pași pentru construir ea diagramei Entitate – Legatură sunt :
 Identificarea entităților care fac parte din sistem .
 Definirea legăturilor între entități și a cardinalității acesto ra
 Indentificarea atributelor sistemului și a cheilor primare ale entităților
 Trasarea diagramei entitate – relație .

13

Figura 2.6 : Diagrama Entitate -Relație
În figura 2.6 este reprezentată Diagrama Entitate -Relație , realizată p arcurgând toți
acești paș i prezentați mai sus și tinînd cont de toate regulile și definitiilor principalelor
componente ale unei astfel de diagrame .

2.2.2. Analiza aplicatiei software a sistemului informatic . Diagrama Procesului
de afaceri
Odată cu termian area analizei bazei de date relaționale , următorul pas constă în
analizarea aplicaiei software pentru sistemul informatic descris în cerinte . Aplicatia software
trebuie să se foloseasca de baza de date , iar analiza lui în acest punct constă în depistarea
principalelor procese care au loc în cadrul sistemului și al factorilor care determină și ajută la
funcționarea corectă a acestor p rocese . Această analiză poate fi realizată cu ajutorul
Diagramei procesului de afaceri (Business Process Model ) .
Diagramei procesului de afaceri (Business Process Model ) :
Este diagrama care descrie în mare vocabula rul afacerii pentru care urmează să fie
implementat sistemul informatic . Reprezintă punctul de pornire în proiectarea acestui tip de

14
aplicaț ie . Scopul acestei diagrame este de a contribui la o cât mai bună înțelegere a procesului
care st ă în spatele afacerii care se bazează pe sistemul in formatic care trebuie creat .
Un proces de afacere ( business process ) este o colecț ie de activitați care sunt menite
să producă un anumit rezultat . Reprezintă o vede re puternică asupra cum este realizată intr -o
companie , în contrast cu vederea pe ca re sistemul o oferă asupra procesului pe care il
reprezintă . Prezinta o ordine riguroasă asupra activităților în timp și spațiu cu un început , un
final , cu date de intrare bine definite și un rezultat care este și el bine definit . Toate acestea
pot fi c onsiderate ca o structură pe care aplicatia software pentru sistemul informatic se
bazeaza .
Principalele componente ale unei astfel de diagrame sunt :
 Actorii
 Evenimentu l care declanșează procesul
 Procesul
 Scopul procesului
 Informații auxiliare
 Resurse necesare procesului
 Rezultatul procesului
Actorii
Un actor este un stereotip al unei clase. Actorii sunt reprezentați de utilizatori sau
entități care pot interacționa cu sistemul. Ei nu fac parte din sistem și definesc mulțimi de
roluri în comunicarea c u acesta . Grafic ei sunt reprezentati sub forma unor mici personaje
având propriul său nume , fig. 2.7 .

Fig. 2.7 : Reprezentare grafică actor
Evenimentul care declan șeaza procesul
Este evenimentul care duce la startul procesului , și este de cele ma i multe ori un
eveniment declanș at de catre un actor . În cadrul diagramei este reprezentat ca un eveniment
public , care este descris printr -un verb . Exemplu fig. 2.8 .

15

Fig. 2.8 : Eveniment declanș ator
Procesul
Un proces reprezintă o activitate care are un sco p bine definit în urma c ăruia se ob ține
un rezultat , de la o condiție inițială . Pentru a -și realiza scopul , procesul se poate folosi de
mai multe resurse . Grafic este reprezentat sub forma unei sageți ingroș ate , iar denum irea
procesului este înc apsulată în cadrul acestei reprezentă ri . Exemplu fig. 2.9 .

Fig 2.9 :Reprezentare proces
Scopul procesului
Un proces are un scop bine definit . Acesta reprezintă motivul p entru care sistemul
funcționează și trebuie să fie exprimat în terme nii cei mai potriviți care arată felul în care
acest proces aduce beneficii pentru sistem și felul în care el satisface nevoile afacerii . Grafic
este reprezentată sub forma unui dreptung hi în care se află scopul , acesta fiind legat de către
casuța de proces printr -o linie discontinuă . Exemplu fig 2.10 .

Fig 2.10 : Reprezentare scop
Informații auxiliare
Procesele utilizează informații pentru a -și indeplinii scopul . Informațiile , spre
deosebire de resurse , nu sunt consumate în cadrul procesului . Aceste informa ții pot veni din
surse externe , de la clienți și pot fi chiar și rezultatul unui alt proces . Spre exemplu ,
Catalogul de produse este considerat ca fiind o informaț ie auxiliară procesului de gestiune a
comenzilor , deoarece procesul se folosește d oar informativ de el , informați ile venite de aici
nefiind în nicun fel modificate pe parcursul procesului .

16
Grafic informațiile auxiliare sunt reprezentate prin casuțe care sunt legate de proces
prin intermediul unor să geți întrerupte pe care se afla textu l supply . Exemplu fig. 2.11 .

Fig. 2.11 : R eprezentare Informație auxiliară
Resurse necesare procesului
O resursă este o dată de intrare în procesul și spre deosebire de informațiile auxiliare ,
ele sunt consumate, și modificate pe parcursul procesulu i . Grafic , res ursele sunt reprezentate
prin că suțe care sunt legate de proces prin intermediul unor s ageți intrerupte pe care se află
textul input . Exemplu fig. 2.12 .

Fig 2.12 : Reprezentare Resurse
Rezultatul procesului
Rezultatu l procesului reprezintă informaț iile și acțiunile care rezultă în urma termină rii
procesului . Grafic sunt reprezentate printr -un drepru nghi unde este scris un titlu câ t mai
reprezentativ pentru obi ectele care rezultă în urma desfășurarii procesului . Exemplu fig. 2.13 .

Fig. 2.13 : Reprezentare rezultat
Cu ajutorul tuturor elementelor descrise mai sus putem reprezenta Diagrama
Procesului de afacere ( Business Workflows Diagram ) . Pentru sistemul informatic descris la
începutul capitolului diagrama procesului de afac ere este reprezentată în fig. 2.14 .

17

Fig 2.14 : Diagrama procesului de afacere pentru sistemul informatic
de gestiune a comenzilor clientilor

Toate elementele prezentate mai sus reprezint ă partea de analiză a cerințelor și
scopurilor Sistemului informatic de gestiune a comenzilor clien ților , analiză care este
necesară pentru realizarea proiectului sistemului și mai apoi pentru implementarea lui .

18
Capitolul 3.
Proiectarea sistemului informatic
Pe baza cerințelor sistemului informatic dar și a datelor rezultate în partea de analiză a
sisteml ui , în contiunare se realizează proiectarea sistemului informatic . Această proiectare se
desfasoară pe două direcții :
1. Proiectarea bazei de date relationale : în acest scop se urmărește descrierea
atributelor entităț ilor , dar și explicitarea legăturilor dintre acestea . Toate
acestea putând fi posibile urm ărind și îmbunatățind diagrama Entitate -Relație
realizată în faza de analiză a sistemlui informatic .
2. Proiectar ea aplicației software a sistemului informatic : are ca scop principal
stabilirea arhitecturii aplicaț iei software a sistemului informatic . Trebuie avut
în vedere felul în care datele sunt gestionate de că tre aplicație , felul în care
aplicația se compor tă la diferiți stimuli și acțiuni venite din partea utilizatorilor
aplicației sau acțiunii altor componente ale aplicației . În același timp trebuie
modelate principalele procese și stări ale aplicației .

3.1 Proiectarea bazei de date relationale .
Pentru a putea proiecta baza de date a sistemului informatic , adică să realiză m
design -ul logic al bazei de date , este necesar ă transformarea schemei conceptuale realizat ă în
cadrul analizei bazei de date , într-un design al bazei de date care trebuie să fie funcțională în
sistemul de gestiune al bazelor de date specific . Aceasta transformare a modelului conceptual
reprezint ă stabilirea unor detalii suplimentare necesare pentru dezvoltarea proiect ului .
Pentru a obține design -ul logic al unei baze de date relaționale este necesar ă pornirea
de la schema conceptual ă a ei , schem ă care este reprezentată în cadrul modelului Entitate –
Relație , pentru care se încearcă reprezentarea entit ăților , lega turilor și a atributelor sub
forma de tabele relaționale detaliate .
Principalele concepte care compun aceasta transformare sunt :
 O entitate devine un tabel .
 O relație se implementează printr -o pereche de chei primară – externă sau printr -un
tabel spe cial , în funcție de caz .

19
 Un atribut al unei enti tăți devine denumirea unei coloane din tabelul care reprezintă
entitatea .
Cheia unei entități .
O cheie a unei entități este un atribut sau un set de atribute care ajuta la identificare în
mod unic a unei o instanțe a aceleași entități . Astfel putem spune că funcția principala a unei
chei este de a face deosebirea intre două randuri ale tabelului provenit dintr -o entitate . De
exemplu consideram că fiecare client va fi identificata în tabela de clienți pr intr-un cod unic (
Id_client ) . Astfel acest cod unic reprezintă este o cheie a entități Client . Alt atribut care
descriu entitatea Client nu ar putea fi considerate chei ale entității deoarece nu pot garanta
uncitatea instanțelor din această entitate . Spre exemplu numele clientului nu poate fi cheie a
entității deoarece pot exista mai mulți clienți cu același nume în muțimea instanțelor entități
Client .
Cheile relaționale pot fi clasificate astfel [1] :
 Supercheie – un atribut sau un set de atribute , care identifica în mod unic o instanța
din interiorul unei relații.
 Cheie candidat – este o supercheie pentru care nicio mulțime adecvată nu este o
supercheie în cadrul relației respect ive . Pentru o relație pot exista mai multe chei
candidate . Atunci c ând o cheie const ă în mai multe decât un atribut , se numeste cheie
compusă .
 Cheie p rimară – este cheia candidat care este selectată pentru a identifica în mod unic
instanțele din cadrul unei relații.
Cheile primare trebuie să respecte o serie de condiții :
– Nu sunt permise valori nedefinite pentru atributele unei chei primare .
– Nicio valoare a unui atribut dintr -o cheie primară nu poate fi modificată în
cadrul operațiilor de actualizare .
Selectarea unei chei primare din mulțimea de chei candidate se face ținând cont de
necesitatea ca numărul atributelor cheii primare să fie cât mai mic posibil . Astfel va fi
desemnată drept cheie primară , cheia candidată care are definite toate valorile
atributelor sale și care are cel mai mic număr de atribute .
 Cheie st răină – este un tribut sau o mulțime de atribute din cadrul unei relații care se
potrivesc cu cele din cheia candidat a unei alte relații .

20
Un alt criteriu important de clasificarea cheilor entităților este clasificarea acestora în
funcție de gradul de ”realism” al atributelor din c are sunt compuse . Astfel există chei naturale
și chei artificiale . Spre exemplu dacă am considera faptul că am putea construi cheia entități
Client din atributele nume, adresa și telefon , atunci aceasta cheie se va numi che ie naturală ,
pentru că aceasta cheie contine atribute care au o semnificație reală . Spre deosebire de o
astfel de cheie naturală , o cheie artificială este o cheie compusă dintr -un atribut fără
semnificație reală pentru entitate , ea fiind ale asă cheie d oar pentru ca asigură unicitatea
instanțelor din acea entitate . Spre exemplu , cheia pentru entitatea Comandă este reprezentată
de catre atributul Id_comanda , atribut care nu are o specificație reală pentru entitatea pe care
o reprezintă .
Cu toate ace stea este de preferat s ă se foloseasca ca și chei primare , cheile artificiale ,
pentru ca acestea prezintă o serie de avantaje :
 Stabilitatea : Valoarea unei chei naturale se poate modifica , lucru care atrage
schimbarea cheilor străine care fac referire l a ea , în timp ce val oarea unei chei
artificiale ramâ ne aceeasi pe parcursul funcționării sistemului informatic .
 Nu prezint ă ambuguități : Aceasta proprietate este de folos pentru ca u șureaz ă filtrările
efectuate în tabele de către dezvoltatori sau utilizatori . De exemplu , specificațiile
unui produs sunt formate din mai multe cuvinte despărțite intre ele de spații sau linii ,
toate acestea ar duce la blocarea sau incetinirea unor operații intre entități .
 Simplitatea : În cele mai multe cazuri chei a artificială este mai simpla decat una
naturală , din puncț de vedere fizic , dar și al spațiului de m emorie pe care îl ocupă .
Acest lucru ajută la o funcționare mai eficientă și rapidă a sistemului informatic .

Transformarea entităților
De regul ă , entitățile devin tabele care au aceleași nume ca și entitățile din care provin ,
dar în funcție de situație , pot să apară câteva cazuri speciale :
 Entitățile independente se transformă în tabele independente : cheia primară a acestor
tabele nu conține chei străine .
 Entitățile dependente se transformă în tabele dependente : tabele a căror cheie primară
conține chei străine ce fac referință la chei primare a entităților de care depinde
entitatea respectivă .

21
Transformarea legă turilor ( relațiilor )
În fun cție de ca rdinalitatea legăturilor dintre entități se disting mai multe criterii de
transformare a leg ăturilor :
 Transformarea legăturii 1:1 . În astfel ce cazuri relațiile 1:1 se reprezintă prin chei
străine . Poziția ei este dată de cardinalitatea minimă a legăturii .
 Transformarea legăturii 1:N . Aceste legăturii devin chei străine puse în tabelul care
se află în partea ”N” a relației .
 Transformarea legăturii N:M . Acest tip de relație se transformă prin crearea unui nou
tabel special , numit tabe l asociativ , tabel conține două chei străine pentru cele două
tabele asociate . Cheia primară a acestui tabel este compusă din aceste două chei
străine plus alte coloane adiționale, dar acestea sunt opționale . Astfel ac eastă relație
putem considera că se desparte în două relații 1:N , tabelul asociativ fiind în aceste
două relații de partea ”1” .

Transformarea atributelor
Regulile după care se face transformarea atributelor sunt :
 Atributele simple ale unei entități se transformă în coloane în tabelul provenit din
entitatea corespunzătoare .
 Atributele repetitive (multivaloare) ale unei entități se transformă în tabele
dependente ce c onțin o cheie străină (care face referință la cheia primară a entității) și
atributul multivaloare .
 Atributele simple sau compuse ale unei relații 1:1 sau 1:N vor deveni coloane ale
tabelului care conțin cheia străină .
 Atributele simple sau compuse ale unei relații N:M vor deveni coloane ale tabelului
asociativ.
 Atributele repetitive (multivaloare) ale unei relații 1:1 sau 1:N vor deveni tabele
dependente de tabelul care conține cheia străină, iar atributele repetitive ale unei relații
N:M vor deven i tabele dependente de tabelul asociativ corespunzător relației.

Tinînd cont de toate aceste reguli de transformare a schemei concept uale a bazei de
date , realizată în modelul Entitate – Legatură , putem crea diagrama logică a bazei de date .
Aceasta e ste reprezentată în figura 3.1.

22

Fig.3.1:Diagrama logică a bazei de date

Tabelele asociate diagramei sunt :
CLIENT ( id_client , Nume , Prenume , Telefon , E -mail )
COMANDA ( id_comanda , id_client )
DETALII_COMANDA ( id_comanda , id_produs , cantit ate ,data_livrare, termen_livrare ,
realizat )
CATALOG_PRODUSE ( id_produs , proiect , date_tehnice , specificatii_produs ,
id_tip_produs )
TIP_PRODUS ( id_tip_produs , nume_tip_produs )
DETALII_PRODUCTIE ( id_comanda , id_produs , id_stadiu , id_sectie , nr_bucati , data_ în
, data_out )

23
STADIU_PROUCTIE ( id_stadiu , nume_stadiu )
SECTIE ( id_sectie , nume_sectie , incarcare )
TIMP_PROD ( id_produs , id_sectie , timp_productie )
PRODUS_MATR_PR ( id_produs , id_material , cant_material )
MATERIE_PRIMA ( id_m aterial , denumire , cant_stoc )
FURNIZORI ( id_furnizor , cantitate , perioada_livrare )
COMANDA_MATERIE_PRIMA ( id_material , id_furnizor , cantitate , data_lansare ,
durata )

3.2 Proiectarea aplicației software a sistemului informatic .
Procesul de proiectare a aplicației sistemului informatic este și el imparțit pe etape
care, treptat ajut ă la anticiparea și pregatir ea sistemului pentru a face față tuturor situațiilor cu
pe care acesta le va putea intalnii pe parcursul perioadei lui de funcționare .
Principalele etape de proiectare sunt :
– Determinarea fluxului de date din interiorul sistemului și construitea
Diagramei Fluxurilor de date ( Data Flow Diagram ) .
– Definirea și analiza cazurilor de utilizare a sistemului informatic , aceste
aspecte ale sistemului sunt conturate în cadrul Diagramei Cazurilor de
Utilizare ( Use Case Diagram ) .
– Proiectarea activității principalelor procese care au loc în cadrul sistemului ,
toate ac estea fiind proiectate în cadrul Diagramelor de Activitate ( Activity
Diagram )
– Determinarea secvențelor prin care trec procesele din cadrul sistemului
informatic pentru a -și indeplini funcțiile . Aceste elemente se stabilesc în
cadrul Diagramelor de secve nțe ( Sequence Diagram ) .
– Determinarea stă rilor prin care trece sistemul informatic în urma unor
evenimente care interacționează cu acesta . Aceasta determinare se face în
cadrul Diagramei de Stare de Tranziție ( State Machine Diagram ) .

24

3.2.1 Diagrama fluxurilor de date
Diagrama fluxurilor de date (Data Flow Diagram) reprezintă o modelare logica a
fluxurilor de date în cadrul sistemului informatic , lucru care ajută la evidențierea legăturii
logice dintre limitele sitemului informatic , a proceselor din interiorul său și a principalelor
entitățile de date .
În principal o astfel de diagramă este construită din obiecte care sunt reprezentate în
raport cu procedurile aplicației , făr ă afisarea niciunei logici de decizie și este utilizată pentru
modelarea fluxurilor de date , dar și pentru realizarea principalelor funcții de prelucrare a
datelor pe care le execută sistemul .
Principalul obiectiv al acestei diagrame este de a urmă rii modul de transfer al datelor
între procesele care le prelucrează . Din aceasta cauză acest tip de diagrame se mai numesc și
modele ale proceselor de preluc rare , iar operațiunea executată mai poartă și numele de
modelare a proceselor .
Diagr ama fluxuril or de date este o m etoda excelentă de rezumare și organizare a
informațiilor detaliate despre limitele sistemului info rmatic , a proceselor , a entită ților
implicate , oferind proiectantului o hartă logică a sistemului informatic . Elementele unei
astfel de diagrame conduc direct la designul fizic al sistemului , unde procesele sugerează
programe și procedur i , fluxurile de date reprezintă colaborarea dintre ele , iar sursele de date
sugerează entități , fisiere și baze de date .
Scopul dia gramelor de flux de date , pentru o anumită componentă organizatorică sau
funcțională la care se referă , este de a reliefa într-o manier ă cât mai sugestivă următoarele
aspecte :
– sursa datelor de prelucrare
– operațiun ile de prelucrare prin care trec datele
– destinația datelor prelucrate
– legătura existentă între prelucrări și activitatea de stocare a datelor

Întocmirea diagramei de flux de date (DFD)

25
Pentru întocmirea unei diagrame a fluxurilor de date care să fie folositoare , există
cateva reguli și informații ajută toare care sunt de folos în mare pentru a evita să construim o
diagrama care este incorectă sau incompletă .
Principalele reguli de intocmire a diagramei sunt :
 Botezarea componente lor și a flux urilor de date : trebuie alese nume câ t mai
sugestive. Proceselor li se asociaz ă la denumire verbe , principalel or entități care
interacționează cu sistemul informatic și obiecte le lor pentru stocarea datelor sunt
asociate substantive , iar fluxurile de date sunt exprimate și ele prin substantive câ t
mai semnificative pentru a exprima datele , tranzitia datelor .
 Numerotarea proceselor : procesele sunt numerotate secvențial , pentru a putea fi
identific ate mai ușor Numere asociate fiecă rui proces nu semnifica și ordinea lor de
execuție .
 Duplicarea entitaților externe : se face în mare pentru a evita intretî ierile , care pot
duce la confuzii în citirea diagramei .
 Plasamentul entităților și a stocurilor de date : entitățile sunt plasate pe cat posibil pe
marginea diag ramei , iar stocurile de date câ t mai în centru .
 Fluxurile de date : fluxurile de date că tre stocurile de date sunt întotdeauna
unidirecționale .

Simbolurile folosite la construcția unei diagrame de flux de date sunt :
Proces : ele sunt etichetate cu text, care arată modul lor de a prelucra datele , iar identificarea
lor se face prin numerotare și o descriere a funcției procesului fig . 3.2 .

Figura 3.2 : Reprezentare proces
Flux de date : este constituit din date care circula în interiorul sistemului informatic . Sunt
etichetate cu un substantiv suge stiv pentru informația transmisă , fig 3.3 .

Figura 3.3 : Reprezentare flux de date

26
Entitate externa : este o sursa sau un receptor de date , poate fi reprezentat și de catre un alt
sistem , fig.3.4.

Figura 3.4 : Reprezentare entitate externă
Stoc de date : reprezintă un depozit de date care poate fi temp orar sau permanent . De cele
mai multe ori este r eprezentarea unei baze de date , fig. 3.5.

Figura 3.5 : Reprezentare stoc de date
Diagrama F luxurilor de date pentru sistemul informatic cerut , con struită în
conformitate cu toate regulile de construcție a unei astfel de diagrame , este urmatoarea
( fig. 3.6 ) .

27

Figura 3.6 : Diagrama Fluxurilor de date ( DFD )

3.2.2 Diagrama cazurilor de utilizare
Diagrama cazurilor de utilizare ( Use Case Diagram ) are scopul de a descrie
comportamentul sistemului informatic , oferind o imagine general ă asupra modului în care va
fi utilizat sistemul astfel furniz înd o privire de ansamblu a func ționalit ăților ce se doresc a fi
oferite de catre sistem . Un alt scop al diagramei cazuri lor de utilizare este de a arata cum
interac ționeaz ă sistemul cu unul sau mai mul ți utilizatori ( actor i ) . Toate aceste a sunt
realizate pentru a certifica faptul că sistemul informatic va produce ceea ce s -a dorit .
Principalele componente ale unei d iagrame a cazurilor de utilizare sunt :
 Actorii
 Cazuri de utilizare

28
 Relații intre actori
 Relațiile intre cazuri de utilizare
 Relații dintre actori și cazuri de utilizare

Actorii
Actorii nu sunt parte a sistemului , ei doar reprezenta nd elemente care interactionează
cu sistemul informatic . El nu participa propriu -zis la prelucrarea datelor din sistem , el fiind
limitat doar la a primi date și introduce date sistemului , astfel acesta poate fi considerat doar
ca un generator de evenimente . Un actor reprezintă o clasa și nu o instanță și are acelasi rol
ca și o entitate externă din di agramele de flux de date , adică de a interacț iona cu sistemul
informatic . Reprezentarea grafic ă în format UML a unui actor este prezentat[ în figura 3.7 .

Figura 3.7 : Reprezentare grafică actor
Identificarea mulțimii actorilor se face prin cunoșterea domeniului problemei , dar și
cu ajutorul analiștilor și a utilizatorilo r . Pentru o cât mai bună identificare a actorilor unui
sistem informatic pot f i cons ultate urmatoarele intrebă ri :
 Care sunt intrarile și iesirile necesare sistemului ?
 De unde vin acestea și unde merg ?
 Unde ar trebui folosit sistemul ?
 Cine va beneficia de pe urma sistemului ?
 Cine va furniza sistemului date , cine le va folosi și cine le va șterge ?
 Cine va administra și intreține sistemul ?
 Cu ce alte sisteme externe va interac ționa ?

La identificarea actorilor , trebuie să se aibă în vedere să nu fie omiși vreunu , iar alții
să nu fie repetați . De exemplu , același actor poate fi observat la momente diferite în timp ,
când interacțiunile lui cu sistemul diferă .

29
Cazuri de utilizare
Un caz de utilizare surprinde o anumită funcț ionalitate a sistemului , din punctul de
vedere al utilizatorilor . Astfel un caz de utilizare poate fi definit ca un set de secvențe de
acțiuni pe care sistemul le realizează pentru a furniza o valoare unui anumit actor . Actiunile
întreprinse de c ătre sistem , pentru furnizarea unui r ăspuns la mesajele transmise de actori ,
pot consta în comunicarea cu alți actori sau alte sisteme , sau doar prin efectuarea unor
prelucr ări . O caracteristic ă important ă a cazurilor de utilizare este aceea ca ele arat ă ce
trebuie s ă facă sistemul și nu cum trebuie s ă facă . Reprezentarea grafic ă a unui caz de
utilizare este prezentată în figura 3.8 .

Figura 3.8 : Reprezentare grafică caz de utilizare
Identificarea cazurilor de utilizare poate incepe dup ă identificarea actorilor , c ând
pentru fiecare actor se pun urmatoarele intrebari :
 Ce funcționalități ale sistemului va trebui să acceseze actorul ?
 Actorul trebuie să citească și/sau să acc eseze actorul ?
 Sunt evenimente din sistem ce trebuie aduse la cunoștinta actorului ?

Descrierea cazurilor de utilizare se face de obicei printr -un tex t care conține o
specificare simplă , dar consistent ă din punct de vedere al mesajului transmis , specificare a
modului de interacțiune între actori și cazurile de utilizare ale sistemului . Descrierea va
surprinde comportamentul sistemului .

Relațiile între actori .
Între actori poate exista relatia de generalizare și constă în faptul că dacă un actor
moștenește un alt actor , atunci el poate să comunice cu aceleasi cazuri de utilizare ale
sistemului c a și pă rintele lui.
Notatia folosita în cazul acestei relații , în UML , este reprezentată de o linie continuă
având în capăt o sageată goală în interior care indică spre actorul părinte . Reprezentarea
grafică a relației de generalizare intre 2 actori este prezentată în figura 3.9 .

30

Fig 3.9 : Reprezentare grafică relația de generalizare între actori

Rela țiile între cazuri de utilizare
Între cazur ile de utilizare pot exista urmă toarele relații : de includere , de extindere, de
generalizare .
 Relațiile de includere : sunt atunci când un caz de utilizare include comportamentul
altui caz de utilizare . Se reprezint ă printr -o săg eată intreruptă , de la cazul de utilizare,
către cazul de utilizare inclus .

Figura 3.10 : Reprezentare relație de includere între cazuri

 Relațiile de extindere : sunt folosite pentru a arăta că un caz de utilizare este inserat în
alt caz de util izare . Extinderea se realizează prin î ndeplinirea anumitor condiții .

Figura 3.11 : Reprezentare grafică relație de extindere intre cazuri
 Relațiile de generalizare : sunt folosite pentru a arăta f aptul că un caz de utilizare
moșteneș te comportamentul altui caz și il imbunată țeste .

31

Figura 3.12 : Reprezentare grafică a relație i de generalizare
Relații dintre actori și cazuri de utiliz are .
Se mai numesc și asocieri și reprezintă o conexiune semantică între actorii și cazurile
de utilizare . Ele reprezintă relaț iile cele mai generale și , din punct de vedere semantic , sunt
relațiile cele mai slabe . O altă caracteristică a asocierilor este aceea că ele sunt
unidirecționale . Reprezentarea grafică a acestei relații este făcută în figura 3.13 .

Fig 3.13 : Reprezentarea relație dintre actori și cazuri de utlizare
Prezentarea diag ramei cazurilor de utilizare.
Diagrama cazurilor de utilizare a sistemului informatic este urmatoarea :

32

Figura 3.14 : Diagrama cazurilor de utilizare
Operator marketing : este acel actor care se ocupă cu procesarea comenzilor . Acesta
operațiune este consecința directă a comenzii clientului . În acelasi timp el se mai ocupă și de
introducerea de noi clienți și mai poate vizualiza comezile existente .
Angajat secție : este acel actor care reprezintă oamenii din cadrul secției de
producție, eu pot doar vedea comenzile atribute lor și se ocupă cu modifi carea stă rii unei
comenzi existente în producție.
Managerul : managerul este acel actor care reprezintă omul sau oamenii responsabili
cu buna funcțio nare a departamentului de producție , in acest sitem informatic , man agerul are
indatorirea de a se asigur a că stocul de materie primă este bine alimentat .
Adaugă noi comenzi : este un caz de utilizare care presupune int roducerea datelor
care corespund unei noi comenzi .

33
Adaugă noi clienți : este un caz de utlizare care presupune ad ăugarea de noi clienți în
baza de date .
Modificare stare comandă secție : este un caz de utilizare care presupune
modificarea starii unei come nzi aflate în producție .
Com andă materie primă : este un caz de utilizare care presupune efec tuarea unei
noi comenzi pentru materie prima .
Adăugare/stergere furnizori : este un caz de utilizare care presupune adăugarea sau
șterger ea furnizorilor de materie primă în baza de date .

3.2.3 Diagrama de activitare

În continuarea proiectarii sistemului informatic , trebuie descrise și explicitate cazurile
de utilizare identificate . Acest lucru se realizaeaza cu ajutorul Diagramelor de activitate
(Activity Diagram ) .
În principiu , o diagrama de activitate reprezintă o metoda simpla și intuitivă de a
ilustra ceea ce se intâmplă în cadrul unui caz de utilizare , sau al unui proces ce se desfasoară
în interiorul sistemului informatic . Prin astfel de diagrame se doreș te prezentarea unor lucruri
ca de exemplu : ce activități pot să fie făcute în paralel , care sunt pașii care se execută , sau
dacă există drumuri diferite pentru execuția unor acțiunii .
Acest tip de diagrame au fost concepute în primă fază pentru modelarea sistemelor la
nivelu ințelegerii bussinesului în care a cestea trebu iesc implementate . În același timp ele se
pliază foarte bine pentru modelarea și detalierea cazurilor de utilizare folosite în cadrul
sistemului informatic .
Pentru sistemul informatic proiectat pana în acest moment , folosim diagramele de
activitate pentru a descrie mai detaliat modul de execuție și activitățile care au loc în cazurilor
de utilizare ale sistemului .
Datorită folosirii în modelarea felului de acțiune a sistemului , sc opul principal pe care
se axează diagrama este de a descrie secventele acțiunilor de executat ș i a condițiilor care
declanșează sau care se impun asupra acțiunilor descrise . Deasemenea diagrama de activități ,

34
se concentrează doar asupra descrierii activității și nu asupra acțiunilor care declanșeaza
activitatea descrisă .
Principalele componente ale unei Diagrame de activitate sunt :
 Activitatea
 Acțiunea
 Punct inițial
 Punct finală
 Tranziția
 Punct de decizie
 Nod de sincronizare
 Culoar

Activitatea
Activitatea în cadrul unei Diagrame de activitate este considerată ca a f iind intreaga
activitate modelată prin diagramă ( formată printr -o succesiune de acțiuni ) . În modelul
orientat pe obiecte activitățile sunt de obicei considerate ca fiind metode legate diferitelor
operațiuni care sunt invocate în cadrul claselor . Datorit ă faptului că definesc întreaga
activitate din cadrul dia gramei de activități , nu există o notație speciala pentru acest tip de
componentă a diagramei .
Acțiunea
O acțiune reprezintă un singur pas într -o diagramă de activitate , un pas care nu mai
este detaliat în continuare în cadrul acestui tip de diagramă . Din punctul de vedere al
activității care o conține , o acțiune este foarte simplă , dar ea poate fi foarte complexă în efect
și construcție . În comparația cu o activitate, care poate fi refolosi tă în mai multe locuri,
acțiunea este o instanță care este folosită doar în cadrul activității în care este î nglobată .
Perioada de viață a unei acțiuni începe de îndată ce toate condițiile ei de funcționare
sunt îndeplinite și în acela și timp , toate da tele de care are nevoie la intrare îi sunt livrate . În
același timp , finalul unei acțiuni declanseaz ă automat începerea execuției altei acțiuni
succesoare acesteia , a c ărei date de intrare corespund cu datele de iesire a acțiunii care se
termin ă .

35
Vizu al , în cadrul diagramei de activitate, o acțiune este reprezentată sub forma unei
”capsule ” , un dreptunghi care are colțurile rotunjite . Textul din interiorul capsulei , indica
acțiunea pe care o reprezintă figura . O astfel de acțiune este reprezentat ă în figura 3.15 .

Figura 3.15 : Reprezentare grafică Acțiune
Punct inițial
Deoarece diagramele de activitate , arată modul de desfașurare al unei activități ,
trebuie indicat și punctul de pornire al activității , punct care reprezintă locul de pornire în
citirea secventei de acțiuni care formeaza diagrama . În cadrul unei diagrame poate să existe
un singur punct de start și de la el poate să plece o singură tranziție către o acț iune .
Grafic , punctul initial a activității este reprezentată sub forma unui punct din care
porneste o tranziție către o acțiune . Reprezentarea grafică poate fi observată în figura 3.16 .

Figura 3.16 : Reprezentare grafică a Punctului inițial
Punct final
Orice activitate descrisă intr -o diagramă de activitate trebuie să aibă un punct de final ,
punct în care activitatea să se oprească . Spre de osebire de punctul de start , o activitate poate
avea mai multe puncte de final . Primul punct final întal nit în parcursul v ieții unei acțiuni ,
declansează automat finalul acelei acțiuni .
Grafic , punctul final a activitătii are o reprezentare asemănătoare cu starea inițială ,
acesta avâ nd în plus un cerc în jurul lui . Reprezentarea grafică poate fi observată în figura
3.17 .

36

Figura 3.17 : Reprezentare grafică Punct final
Tranziția
Tranziția într-o diagramă de activitate arată întotdeauna ordinea de execuție a
acțiunilor din cadrul activității descrise . Tranziția este reprezentată sub forma unei săgeți care
întotdeauna arată către acțiunea care urmează să se execute . Reprezentarea grafică a unei
tranz iții între două acțiuni poate fi observată în figura 3.18 .

Figura 3.18 : Reprezentare grafică Tranziție intre două acțiuni
Punct de decizie
În cadrul unei digrame de activitate pot exista locuri în care să trebuiasca luate
anumite decizii în funcție de rezultatul de la iesirea unei acțiuni . În modelarea unor astfel de
cazuri , este nevoie de modelarea a dou ă sau mai multe secvențe d e acțiuni . Modelul de
realizare a unor astfel de decizii este printr -o tranziție care vine dinspre o acțiune catre punctul
de deci zie , iar din acesta pleaca două sau mai multe tranziții că tre alte acțiuni , în funcție de
rezultatul asupra că ruia se efect uează decizia .
Reprezentarea grafică a unui punct de decizie este sub forma unui romb în care intră o
tranziție și ies alte două sau mai multe tranziții . Valorile în funcție de care se face decizia
sunt trecute pe tranzițiile care ies , și sunt incadra te intre paranteze pătrate . Reprezentarea
poate fi observată în figura 3.19 .

37

Figura 3.19 : Reprezentare grafică a Punctului de decizie
Nod de sincronizare
Un nod de sincronizare este un nod în care o tranziție este desparțită în două , practic
în el intră o tranziție și ies două tranziții . Poate fi folosit în modelarea a mai multe fire de
execuție care fac pa rte din aceeasi activitate . Reprezentarea grafică poate fi observată în
figura 3.20 .

Figura 3.20 : Reprezentare grafică Nod de sincronizare

Pentru sistemul informatic care trebuie implementat avem mai multe activități care
trebuie modelate cu ajutorul Diagramei de activitate .
Una dintre cele mai importante activități este Activitatea de introducere a
comenzilor clienților . Introducerea propriuz isă se face de catre Operatorul de Marketing pe
baza cerintelor exprimate de către client . Această activitate presupune executarea acțiunilor
de logare , introducera datelor clientului , vizualizarea catalogului de produ se , selectarea
produselor , adăugarea numă rului de produse dorite , și adăugarea comenzii în baza de date .
Pe parcursul aces tei activități se deosebesc două puncte de decizie . Primul după acțiunea de
logare a operatorului , dacă această operațiune esuează , activitate a ia sfarsit . Al doilea pun ct
este după adă ugarea unui produs . În acest moment se poat e opta pentru adă ugarea la
comandă și a altor produse , iar in cazul în care se dorește acest lucru , se face o intoarcere la
acțiunea de vizualizare a catalogului de p roduse . Diagrama descrisă mai sus este reprezentată
în figura 3.21 .

38

Figura 3.21 : Diagrama de activitate pentru activitatea de Adaugare a unei comenzi
La fel de importantă este și Diagrama de activitate pentru Adă ugarea unei noi
comenzi catre furnizorii de materie primă . Activitatea este realizată de catre Manager și
este declanșată de inițierea unei noi comenzi de că tre manager . Acțiunile derulate în cadrul
activității sunt acțiunile de logare , vizualizare a stocului de materiale , completa re a comenzii
și de trimitere a acesteia . Punctul de decizie din această diagramă este situat după acțiunea de
logare , iar dacă logarea nu s -a efectuat cu succes se realizeaza termi narea activității .
Diagrama descrisă se află reprezentată în figura 3.22 .

39

Figura 3.22 : Diagramă de activitate pentru Adaugarea unei comenzi catre furnizorii de
materie primă

Una din tre cele mai folosite activități din cadrul sistemului informatic , va fi
Activitatea de vizualizare a comenzilor care sunt în derulare . Ace asta operațiune poate fi
realizată de către Operatorul de Marketing sau Manager și presupune realizarea acțiunilor de
logare și de vizualizare a stadiului comenzilor . S ingurul punct de decizie se află după
acțiunea de logate , moment în care dacă această operațiune eșuează se realizează terminarea
activității . Reprezentarea acestei activități se face în cadrul figurii 3.23 .

40

Fig 3.23 : Diagrama de activitate pentru vizualizarea comenzilor aflate în producție .

3.2.4 Diagrama de stare a tranzițiilor
Diagrama de stare a tranzițiilor ( State Diagram ) este folosită pentru a reprezenta
stările prin care trec anumite obiecte , evenimente care determin ă tranziția de la o stare la alta
, dar și circumstanțele și condițiile aplicate pentru realizarea tranzițiilor . Acest tip de
diagrame se construiesc pentru clasele a c ăror com ponente sunt afectate de schimbă ri de stare
ale obiectelor care le compun . [5]
Scopul acest or diagrame este de a descrie ră spunsul și comportarea diferitor obiecte la
mesaje externe , dar și de a reprezenta și secvențele de stări prin care trec acele obiecte pe
parcursul existenței lor . Acest tip de diagrame se pliază pentru obiect ele instanțiate ale unei
clase sau unor cazuri de utilizare , din cadrul diagramei cazurilor de utilizare .
Componentele principale ale u nei diagrame de tranziție sunt : stă rile , tranzițiile ,
punctele de decizie , punctele de intratre și de ieșire .

41
Starea
O stare este definită de c ătre mul țimea valorilor proprietăților unui obiect , dar și de
totalitatea mesajelor care pot fi acceptate de către obiect . O stare are ca și alcătuire , acțiuni
inițiale , acțiuni finale și tranziții interne , care la randul lor pot fi alcătuite din mai multe
acțiuni .
Grafic , o stare este reprezentată sub forma unui dreptunghi cu colțuri rotunjite , iar în
interior este afisat un nume sugestiv pentru fiecare stare . Reprezentarea grafică a unei stări
poate fi obser vată în figura 3.24 .

Figura 3.24 : Reprezentarea grafică a unei stări
Tranziția
Tranziția exprimă trecerea de la o stare la alta și poate fi folosită și pentru a prezenta
acțiunile care se impun acestei treceri .
Grafic , tranzițiile între două stări se reprezintă prin intermediul unor arce de cerc sau
linii drepte , pe car e pot fi trecute , opțional acț iunile care au loc pe parcursul tranzițiilor .
Reprezentarea grafică a unei tranziții poate fi observată în figura 3.25 .

Figura 3.25 : Repreze ntare grafică a unei Tranziții
Punctele de intrare și de ieșire
Punctul de intrare și de ieșire al diagramei reprezintă punctele din care pleacă și se
termină tranziția stărilor prin care trece obiectul . Grafic , ele sunt reprezentate la fel ca în
diagramele de activitate , figura 3.25 .

Figura 3.25 : Reprezentare grafică punct de intrare și punct de ieșire

42
Puncte de decizie
Sunt puncte care permit împărțirea tranziției în mai multe direcții , iar decizia care
arată direcția în care se va merge poate fi reprezentată de către o funcție care evaluează
tranziția care intră și în funcție de condiția care guvernează acel punct se face conexiunea
către una din tranzițiile care se continuă .
Reprezentarea grafică este sub forma unui romb în care intră o tranziție și ies două sau
mai multe tranziții . Exemplu figura 3.26 .

Figura 3.26 : Reprezentare grafică Punct de decizie
Pentru sistemul informatic proiectat pâna în acest moment , sunt necesare alcătuirea a
două diagrame de stare a tranzițiilor . Prima trebuei alcătuită pentru a detalia stările prin care
trece sistemul informatic în momentul introducerii unei noi comenzi , iar cealaltă detaliază
stările prin care trece un obiect al clasei comandă , pe parcursul vieții acestuia în cadrul
sistemului .
Stările prin care trece sistemul informatic în momentul în care se execută procesul de
adăugare a unei noi comenzi încep cu s tarea în care datele clienților au fost adaugate și se
continu ă cu starea în care se vizualizează catalogul de produse , starea în care se alege
produsul care se dorește a fi adăugat și starea în care sunt adăugate nu mărul de produse .
După această stare u rmează un punct de decizie , punct din care se poate reveni l a starea în
care se vizualizează catalogul de produse din nou , în vederea adăugării unui alt produs , sau
se poate continua cu starea de Comandă lansată , stare care este și starea finală a sist emului .
În figura 3.27 se poate observa această diagrama de stare a tranzițiilor pentru sistemul
informatic , în momentul introducerii unei noi comenzi în sistem .

43

Figura 3.27 : Diagrama de stare atranzițiilor sistemului informatic la adăugarea unei
comenzi

Pentru a detalia stările prin care trece un obiect al clasei comandă , pe parcursul vieții
acestuia trebuie construită o altă diagramă de stare a tranzițiilor .
Comanda , din momentul lansării ei și până la livrare trebuie să trecă prin difer ite
stadii din procesul de producție . Fiecare stadiu este realizat în secții diferite , ele având o
derulare succesivă , de la prima secție , secția de DEBITARE , până la ultima , secția de
ASAMBLARE . În momentul în care o nouă comandă este lansată , a ceasta este programată
pentru a intra în prelucrare succesiv, în fiecare dintre secții . Comanda nu poate trece de la o
secție la alta până aceasta nu a fost îndeplinită în secțiile precedente . Ordinea secțiilor prin
care trebuie să treacă o comandă sunt : DEBITARE , PRELUCRARE și ASAMBLARE . O

44
comandă se consideră ca fiind realizată într -o secție în momentul în care Angajatul din
producție responsabil bifeaz ă comanda respectivă ca fiind îndeplinită . Diagrama stărilor de
tranziție prezentată mai sus este reprezentată în figura 3.28 .

Figura 3.28 : Diagrama stărilor de tranziție prin care trece o comandă din momentul lansării
și până în momentul terminării acesteia .
3.2.5 Diagrama de secvențe
Diagrama de secvențe ( Sequence Diagram ) este o diagramă care se analizează și
detaliază aspectul temporal al obectelor și al interacțiunilor dintre acestea . Grafic ea poate fi
considerată o diagramă bidimensională deoarece are elementele împarțite pe două dimensiuni
( ca pe o axă de coordonate XOY ) . Pe axa OX sunt reprezentate principalele obiecte care
compun diagrama . Pe axa OY este reprezentat pentru fiecare obiect timpul , ca o linie
punctată , poziționată paralel cu această axă imaginară , linie c are se mai nume ște și ” linia
vieții ” unui obiect sau în limba englez ă ” lifeline ” . Pe baza acestor reprezent ări , tot pe axa
OY se aranjează , ordonate crescător în funcție de timp , a mesajel or și datel or care se transmit

45
între obiecte . Perioada în care un obiect pre ia controlul sau efectuează o acțiune , este
reprezentată sub forma unui dreptunghi în dreptul linie punctate .
Scopul unei astfel de diagrame este de a crea o idee asupra cum preiau obiectele
acțiunea în anumite situații și asupra felului în car e acestea se comportă și interacționează
între ele , toate aceste lucruri fiind analizate având în vedere caracteristica cronologică și a
timpului în car e acestea îsi desfășoară activitatea .
Principalele elemente ale unei diagrame de se cvențe sun t : obiectele , linii le de viața și
mesajele .
Obiectele
Obiectele sunt elementele principale ale diagramei , ele sunt entitățile care în cadrul
diagramei intevin în prelucrarea datelor , prin transmisia și recepționarea de mesaje .
Grafic ele pot avea mai multe reprezentări , în funcție de entitatea pe care o reprezintă
(figura 3.29 ) , dar principala reprezentare în cadrul diagramei de care avem nevoie este sub
forma de dreptunghi . Ele sunt plasate orizontal în partea de sus a diag ramei .

Figura 3.29: Diferite reprezentări grafice ale obiectelor
Liniile de viață
Liniile de viață a obiectelor au rolul de a evidenția durata de viață a obiectelor . Grafic
ele sunt reprezentate prin dreptunghiuri atașate liniilor verticale punct ate care pornesc de la
fiecare obiect . Reprezentarea grafică poate fi observată în figura 3.30

Figura 3.30 : Reprezentarea grafică a unei linii de viață

46
Mesaje
Mesajele reprezintă elementele cu care oiectele comunica între ele . Ele pot sugera
element e ca apeluri de funcții și pot fi însoțite de condiții asupra transmiterii mesajelor , dar și
cu parametrii care țin de mesajul transmis . Grafic sunt reprezentate sub forma unor săgeți
care unesc liniile de viață ale obiectelor .
După felul în care se face prelucrarea datelor , mesajele pot fi clasificate în 3 categorii:
 Mesaje sincrone : sunt mesajele după care se asteaptă termianrea completă a
prelucrării indicate de către acesta . La sfârșitul prelucrării există opțiunea de furnizare
a unui raspuns .
 Mesaje asincrone : sunt opusul mesajelor sincrone și indică faptul că se poate începe și
realiza o nouă prelucrare , chiar dacă nu s -a finalizat prelucrarea în curs .
 Mesaje simple : sunt mesajele pentru care nu sunt este specificat faptul dacă sunt
sincrone sau asincrone .

În acest moment al proiectării sistemului i nformatic se face identificarea mesajelor
care apar între diferite clase ale sistemului informatic . În același timp , acest moment este și
momentul în care se stabilesc complet operațiile care au loc între clase .
Pentru a exemplifica cele menționate ma i sus , considerăm Diagrama de secvențe
pentru secvențele prin care trece fiecare obiect al clasei Comandă . Diagrama poate fi
observată în figura 3.31 .

47

Figura 3.31 : Diagrama de secvențe pentru obiectele clasei Comandă
După cum se poate observa din c adrul diagramei prezentată mai sus ( fig 3.31 ) se
poate distinge faptul că fiecare obiect nou al clasei Comandă trece prin următoarele secvențe
de activitate pe parcursul vieții sale .
1) Operatorul de Marketing introduce o nouă comandă în sistemul informa tic .
2) Se face verificarea stocului de materie primă și se așteaptă aprobare .
3) Dacă stocul permite , se face aprobabrea comenzii .
4) În acest moment comanda este trimisă departamentului de producție .
5) După ce comanda a fost realizată se face livrarea acestei a .

48
Capitolul 4.
Implementarea sistemului informatic
Implementarea este procesul prin care algoritmul obținut în urma fazei de proiectare a
sistemului informatic , în limbaj de programare . De realizarea acestei faze a dezvoltării unui
sistem informatic se ocupă de obicei un programator sau o echipă de programatori .
În ansamblu , implementearea , presupune traducerea algoritmului din faza de
proiectare în limbajul de programare ales pentru dezvoltarea aplicației . Pentru realizarea cat
mai corectă a implementării , acest procedeu presupune ca persoana care îl realizeaz ă , să
cunoasca foarte bine atât limbajul de programare în care se doreste implementa t sistemul, dar
și a limbajului în care este realizată faza de proiectare .
Implementarea sistemului informatic proiectat pâna acum poate fi structurată pe două
direcți i :
1. Implementarea bazei de date a sistemului informatic
2. Implementarea aplicației software a sistemului

4.1. Implementarea bazei de date
Această fază a implemantării aplicației presupune transformarea designului logic al
bazei de date , realizat în faza de proiectare , într -o structură fizică eficientă , specifică pentru
sistemul de gestiune al bazei de date folosit .

4.1.1. Limbajul SQL
Structure d Query Language ( SQL ) , în prezent , este unul dintre cele mai puternice
limbaje structurate folosit pentru a defini , interoga , reactualiza și gestiona bazelor de date
relaționale .
Ca și structură este considerat ca fiind un limbaj neprocedural și d eclarativ , lucru care
reiese din faptul că , utilizatorul , pentru a obține datele dorite , este nevoit doar să descrie
datele dorite și nu să stabilească modalitatea de ajungere și procurare a datelor respective . În
acelasi timp , SQL nu poate fi consid erat ca un limbaj de programare sau unul de sistem , ci

49
mai degrabă poate fi considerat ca fiind un limbaj de aplicație , datorită orientării acestuia
asupra mulțimilor . Este foarte eficient în administrarea bazelor de date de tip client/server ,
clientul fiind cel care generează instrucțiunile SQL .
Implementarea limbajului SQL se poate face av ând în vedere 3 meto de prin care acest
lucru se poate realiza :
 Apelarea directă : constă în introducerea instrucțiunilor direct din prompter.
 Apelarea modulară : foloseste procedeuri apelate de programele aplicației .
 Apelarea încapsulată : conține instrucțiuni încapsulate în codul de program .

Instrucțiunile din cadrul limbajului SQL pot fi grupate în mai multe categorii , în
funcție de rezu ltatul obținut în urma executării lor . Având în vedere acest aspect , avem
următoarele grupuri de instrucțiuni : instrucțiuni de definire a datelor , instrucțiuni de
manipulare a datelor , instrucțiuni de selecție a datelor , instrucțiuni de control a dat elor .

4.1.2. Prezentare generală Microsoft SQL Server
Pe lâ ngă toate softurile de success , dezvoltate în ultimii ani , firma Microsoft este
prezentă și pe segmentul sistemelor de gestiune a bazelor de date , cu trei produse : Access ,
Visual FoxPro și SQL Server . Dintre acestea cel mai important și mai rasp ândit este SQL
Server , software care de la lansarea primei versiuni a să în anul 1989 și pană în prezent a
ajuns unul dintre cele mai importante și folosite sisteme de gestiune a bazelor de date prezente
pe piață în acest moment . În prezent SQL Server se află la versiunea SQL Server 2008 .
SQL Server este în categoria servere -lor de baze de date , categori a sisteme lor de
gestiune a bazelor de d ate care facilitează realizarea aplicațiilor client -server , aplicații care
permit accesul concurent la baza de date .
Principalele caracteristici care au facut din SQL Server , unul din cele mai r ăspandite
și utilizate SGBR -uri ( sistem de gestiune a baz elor de date ) sunt :
 Datorită faptului ca are un model de programare asemanator celui al Windowsului ,
acesta face utilizarea lui mai ușoara .
 Este optimizat pentru a face față și gestiona baze de date foarte mari , baze de date
care pot ajunge ca și dimensiuni , la cateva sute de megabiti .

50
 O altă caracteristică importantă este ușurința în instalare, utilizare și dezvoltare de
aplicații , SQL Server deținînd diferite instrumente de administrate și dezvoltare a
aplicațiilor.
 SQL Server poate fi rulat de pe o varietate largă de echipamente hardware , pornind
de la simple laptopuri și pana la sisteme hardware complexe g en servere
multiprocesor .
 În cazul platformelor multiprocesor, procesul de interogare poate fi împ ărțit în mai
multe părți , fiecare f iind executată de către un alt procesor . La sfârșit , rezultatele
sunt combinate pentru alcătuirea răspunsului final . Astfel se face o optimizare a
inteogării , optimizare care ajută la reducerea substanțială a timpului necesar
execuției. Acest lucru est e foarte important în momentul în care se lucrează asupra
unor baze de date foarte mari .
 Începand cu versiunea SQL Server 2000 , ace asta permite lucrul cu documente XML .
 Sql server poate fi intergrat cu alte produse software , gen servere de e -mail , sa u
servere de web .

4.1.3. Baze de date în SQL Server
SQL Server oferă foarte multe facilități pentru buna funcționare si administrare a
bazelor de date care sunt administrate și realiza te cu ajutorul lui . În acest sens au fost
dezvoltate o serie de utilitare care sunt menite să ajute și să simplifice atribuțiile utilizatorilor .
Printre aceste utilitare , cele mai importante sunt :
 Au fost concepute mai multe baze de date , numite baze de date sistem , utilizate la
funcționarea corectă a SQL Server .
 O altă caracteristică importantă este dată de către felul în care SQL Server îsi
organiz ează fizic bazele de date care sunt administrate cu ajutorul acestei aplicații .
Bazele de date sist em
În cadrul SQL Server există patru astfel de baze de date : model , tempdb , msdb și
master .
– Baza de date model : este o bază de date model , iar o nouă copie a acesteia este
creată de fiecare dată când un utilizator crează o nouă bază de date .
– Baza de date tempdb : este o bază de date utilizată pentru memorarea datelor
temporare ( tabele sau rezultate temporare ale unor interogări ) .

51
– Baza de date msdb – utilizată pentru a stoca date referitoare la sarcinile pe care
”Agentul ” folosit de către SQL S erver trebuie să le execute periodic ( backup , etc .)
– Baza de date master – este o bază de date care conține configurările specifice SQL
Server , dar și date despre utilizatorii bazelor de date .

Organizarea bazelor de date
Fizic , bazele de date crea te și stocate cu ajutorul SQL Server , prezintă anumite
particularități care fac accesarea datelor mai ușoară , dar și facilitează recuperarea datelor
stocate în cazul apariției unei erori .
Ca și formă de stocare , o bază de date poate avea cel putin dou ă fisiere : un fișier
primar de date ( con ține datele stocate ) , un fi șier jurnal ( stochează toate modificările
efectuate asupra bazei de date ) .

4.1.4. Elemente ale limbajului SQL în cadrul SQL Server
Limbajul SQL oferă posibilitatea de execuție a unei multitudini de operații și
interogări asupra unei baze de date . Aceste operații pot p leca de la definirea și crearea
propriuzisă a unei baze de date , crearea tabelelor cu toate componentele lor , modificarea
tabelelor și a tiputilor de date și componente cuprinse în el , și pot ajunge până la simple
interogări ale bazei de date pentru extragerea anumitor date din componența lor .
Toate aceste operații sunt posibile cu ajutorul SQL Server , dar cele mai importante
sunt acelea care țin de crearea bazei de date și definirea a tot ce ține de ele , dar și operațiile
care ne ajută în prelucrarea mai ușoară a datelor ( creare ve derilor sau a procedurilor stocate ) .
Una dintre cele mai importante comenzi este cea de creare a unui tabel . Comanda
necesară este comanda CREATE TABLE . Pentru a exemplifica cât mai bine elementele care
țin de crearea și definirea principalelor elemente ale unui tabel , în cele ce urmează v om crea
tabelul Client .
GO
CREATE TABLE [dbo].[Client](
[id_client] [int] IDENTITY(1,1) NOT NULL,
[Nume] [nvarchar](50) NULL,
[Prenume] [nvarchar](50) NOT NULL,
[Telefon] [numeric](18, 0) NOT NULL,
[E_mail] [nvarchar](50) NULL,
)

52
În cele scrise mai sus , am creat tabelul Comanda care conține campurile : id_client ,
Nume , Prenume , Telefon , E_mail . Campurile id_client ,Prenume și Telefon , sunt c âmpuri
care nu pot conține valori nule . Campul id_client va fi incrementat cu unu fa ță de valoarea
precedentă pentru fiecare rând nou din tabel , acest lucru este realizat datorită prezenței
opțiunii IDENTITY(1,1) .
În continuare trebuie setat ă cheia sau cheile primare a tabelei , dar și cheile str ăine
către alte tabele , dacă există asa ceva . Această operațiune se face cu ajutorul comenzii
ALTER TABLE , comanda care dă posibilitatea utilizatorului să modifice elemente din cadrul
unui tabel deja creat . Pentru tabelul creat mai sus , acest luctu se realizează astfel :

GO
ALTER TABLE [dbo].[Client] ADD CONSTRAINT [PK_Client] PRIMARY
KEY([id_client])
GO
ALTER TABLE [dbo].[Client] ADD CONSTRAINT [FK_Comanda] FOREIGN
KEY([id_client])
REFERENCES [dbo].[ Comanda] ([id_client])

4.2. Implementarea aplicației software a sistemul ui informatic .
În implementarea unei aplicații software se disting 3 nivele de implementare :
 Nivelul Prezentare : este reprezentat de către interfața utilizator , pe care programul o
prezintă .
 Nivelul Logic : reprezintă codul din spatele interfeței și care face ca programul să
funcționeze corect .
 Nivelul Acces la date : nivel care va avea rolu de stocare a datelor utilizate de către
program . În general aplicațiile impel emntează clase care se ocupă de treaba din acest
nivel .
Chiar înainte de a începe proiectare , persoanele raspunzătoare de acest lucru trebuie
să aibă o privire de ansamblu asupra ceea ce aplicația dorește să realizeze . O dată ce aceste
lucruri au fost stabilite , se poate trece la alegerea tehnologiilor în care va fi implementată
aplicația, iar următorul pas este implementarea ei .

53
4.2.1. Microsoft .NET
Tehnologia .NET , dezvoltată de către Microsoft începand cu anul 2002 este o
platformă de calcul care simplifică dezvoltarea apl icațiilor , în special a aplicațiilor în mediul
distribuit al Internetului . Platforma creată se numeste ”.NET Framework” care urmărește în
principal satisfacerea următoarelor cerințe în dezvoltarea aplicațiilor :
 Oferirea unui mediu consistent de programa re , orientat -obiect , indiferent dacă codul
obiectului este stocat și executat local , sau executat local dar distribuit pe Internet ,
sau executat la distanță .
 Oferirea uni mediu de execu ție a codului care să minimizeze desf ășurarea software –
ului și conflictele de versiune .
 Oferirea unui mediu de execuție a codului care să garanteze execuția sigură a codului
 Oferirea unui mediu de execuție a codului care să elimine problemele de platformă .
 Să facă experiența dezvoltatorului consistentă în cazul variat elor tipuri de apl icații ,
cum sunt aplicațiile Web -based și aplicațiile Windows -based .
Principalele caracteristici ale platformei .NET sunt :
– Este un framewo rk care este independent de platforma pe care operează .
– Poate fi considerat ca fiind un strat î ntre sistemul de operare și limbajul de
programare.
– Suportă peste 20 de limbaje de programare , inclusiv VisualBasic.NET , C# și multe
altele .
– Oferă un set comun de biblioteci de clase , set care poate fi accesat din orice limbaj de
programare .NET . Astf el cunoașterea oricărui limbaj .NET , va fi deajuns pentru
scrierea codului .NET , toate acestea pentru că nu vor exista seturi de clase diferite
pentru fiecare limbaj .
– Ca o caracteristică care va urma , va fi aceea că pe versiunile viitoare de Windows ,
.Net va fi distribuit gratuit ca parte a sistemului de operare , iar utilizatorii nu vor mai
fi nevoiți să -l instaleze separat .
Common Language Runtime (CLR) , sau în traducere Unitatea de execuție a
programelor , integrată în platforma .NET este componenta responsabilă pentru serviciile
run-time cum sunt integrarea de limbaje , întărirea securității și managementul memoriei ,
proceselor și firelor de execuție . O altă responsabilitate a CLR o putem regăsi în timpul
dezvoltării aplicației , cand trăsături cum ar fi managementul ciclului de viață , numirea

54
tipurilor de date , tratearea excepțiilor între limbaje și legarea dinamică reduc cantitatea de
cod pe care dezvoltatorul trebuie să o scrie .

4.2.2. Limbajul C#
Limbajul de programare C# este un limbaj integrat în platforma .NET , limbaj
dezvoltat de către compania Microsoft , pornind de la limbajul C++ .
C# este un limbaj ”simplu” din punct de vedere a numărului de cuvinte cheie din care
este alcătuit și a tipurilor de date predefinite în cadrul lui . Acesta conține doar 80 de cuvinte
cheie și 12 tipuri de date . Conform percepțiilor moderne ale programării , C# se adaptează
acestora , prin permiterea programării structurate , modelată și orien tată-obiect .
Sintaxa și principiile de programare a limbajului C# sunt moștenite de la limbajul
C++. Totusi C# a p ăstrat sau a eliminat diferite elemente din C++ . Principalele asemănări și
modificări între cele două limbaje sunt :
– Au fost adăugate o ser ie de tipuri noi de date , pentru realizarea unor secvențe de cod
cât mai sigure .
– Au fost adăugate unele funcții noi , de exemplu interfețe și delegări .
– Unele tipuri de date au fost modificate , de exemplul tipul struct și tipul string au fost
modificat în C# .
– Din C# a fost eliminată moștenirea multiplă și pointerii către funcții .
– O componentă importantă din C++ care a fost păstrată și în C# este accesul la
memorie direct , folosind pointeri , dar în limbajul C# aceste zone de cod sunt
considerate ca f iind nesigure .
– Elementele fudamentale ale limbajului C# au fost considerate ca fiind elementele de
bază ale programării pe obiecte : încapsularea, moștenirea și polimorfismul .

Principalele componente ale unei aplicații dezvoltate în C# sunt clasele . Ca și
organizare , acestea sunt organizate în spații de nume ( namespaces ) , spații care au
proprietatea că conțin clase de nume diferite , dar cu funcționalitate înrudită .
O clasă este un obiect format din date și funcții . Pentru apelarea unei funcți i în cadrul
clasei în care a fost definită se face prin apelarea cu numele acesteia . Apelul unei funcții se

55
poate face atât din clasa în care este definită , cât și din altă clasă , iar în acest caz trebuie
specificat numele clasei din care provine și dupaia a numelui funcției astfel : clasă.nume .

4.2.3. Clase incluse C#
În cadrul limbajului C# au fost introduse , de către cei de la Microsoft mai multe clase
care facilitează acc esul la date . Aceste clase au fost introduse în cadrul tehnologiei
ADO.NET ( ActiveX Data Objects ) , tehnologie care oferă o flexibilitate sporită pentru
accesul la date , dar în același timp face această operațiune mult mai ușoară .
Clasele puse la dispoziția programatorilor de către această tehnologie sunt în numar de
7 și sunt urmatoarele :
 DbConnection
 DbCommand
 DbDataReader
 DbDataAdapter
 DataSet
 DataRelation
 DataTable
Dintre acestea cele mai importante pentru aplicația software a sistemului informatic
proiectat până în acest punct sunt : DbConnection și DbCommand .
DbConnection
Este clasa care realizează și furnizează conexiunea cu baza de date . Pentru realizarea
cone xiunii este nevoie de instanțierea unui nou obiect de tip DbConnection , precizînd în
același timp o serie de informații referitoare la baza de date : locația bazei de date , nume le
utilizatorului , parola și numele bazei de date .
Această clasă este ce -a mai important ă dintre toate clasele care lucrează direct cu baza
de date , deoarece toate clasele care execut ă interogări sau modificări în baza de date , vor
utiliza această clasă pentru a -și putea realiza sarcinile .
Conexiunea efectivă cu b aza de da te se realizează cu ajutorul unui șir de conexiune
(connection string ) , șir stocat în parametrul ConnectionString al clasei DbConnection .

56
Instanțierea unui nou obiect al acestei clase nu înseamna neaparat realizarea unei
conexiuni cu baza de date . Pe ntru conectarea și deconectarea la baza de date , clasa
DbConnection oferă metodele Open() și Close() . Acest lucru este realizat pentru că de multe
ori nu este nev oie ca să avem o conexiune continuă cu baza de date .
Clasa DbConnection poate avea mai multe clase derivate , acestea , împreună cu clasa
principală au denumirea de clase de conexiune . De exemplu clasa SQLConnection este o
clasă derivată a clasei DbConnection , clasă folosită în cazul în care baza de date este realizată
cu SQL Server .
În cadrul aplicației realizate , definirea și realizarea legăturii cu baza de date se
realizează cu ajutorul clasei derivate SQLConnection astfel :
public SqlConnection con = new SqlConnection("Data Source=MIHA –
PC\\SQLEXPRES S;AttachDbFilename=C: \\Users\\miha\\Desktop\\licenta\\PROGRAM_
PRACTIC\\proiect\\baza_date \\dataBase_project.mdf;Integrated
Security=True");
Se declară o variabilă de tipul SQLConnection la care i se atasează stringul de
conexiune cu b aza de date . Aceast ă operațiune are loc în cadrul unei clasei Conexiune clasă
care este creată cu scopul de a realiza conexiunea cu baza de date . Astfel la executarea unei
comenzi este suficientă declararea unui obiect de tipul clasei de conexiune , care la sf ârșitul
execut ării comenzii va fi șters . Astfel se evită scrierea codului de conexiune pentru fiecare
instrucțiune SQL care trebuie executată din cadrul programului .
DbCommand
Este clasa care implementează operația de interacțiune directă cu baza de date . Cu
ajutor ul obiectelor de tipul DbCommand vor putea fi executate interogările SQL , procedurile
stocate și cam tot ceea ce ține de comenzile SQL asupra bazei de date .
Această clasă , împreună cu clasele derivate din ea sunt denumite clase de comandă .
Propriuzis , o comandă sql care trebuie executată este inserată în cadrul unui string ,
care va fi stocat în cadrul variabilei CommandText . Accesarea conexiunii corespunzătoare se
va face utilizând metoda DbCommand.Connection .
La fel ca și în cazul cla se DbConnection , și aici există clasa SQLCommand , care este
o clasă derivată a DbCommand și este folosită în cazul folosirii SQLServer .

57
SqlCommand cmd = new SqlCommand();
cmd.CommandText = "SELECT id_produs,denumire FROM
Catalog_produse";
cmd.Connection = ob.con;
…
result = cmd.ExecuteReader();
Mai sus este definită comanda pentru extragerea din tabela Catalog_produse a id -ului
unui produs și a denumirii acestuia . C omanda SQL de executat este definită cu ajutorul clasei
SQL Command . Campul CommandText al variabilei definite conține Comanda SQL care
trebuie executată , iar campul Connection ține conexiunea cu baza de date realizată în acest
exemplu cu ajutorul obiectului ob . Executarea propriuzisă a comenzii se face la exe cutarea
cmd.ExecuteReader() iar rezultatul este stocat în șirul result .

4.2.4. Concluzii
Alicația Sietem informatic de gestiune a comenzilor clienților este proiectată pentru
a gestiona și programa eficient comenzile unei firme de producție .
Principalele caracteristici ale acestui sistem informatic sunt :
– Sistemul este proeictat pentru a fi o componentă dintr -un sistem informatic mult mai
complex care deservește întreaga activitate cuprinsă în cadrul firmei . Din această
cauză sistemul proiectat se ocupă doar de parte de programare a producției și de
gestiunea stocu lui de materiale , iar alte activități , cum ar fi activitatea economică sau
de gestiune a personalului , din cadrul unei organizații fiind ignorate de către această
aplicație .
– Sistemul perimite accesul la informații separat în funcție de pozi ția ocupată în cadrul
organizației , funcții care sunt definite în cadrul diagramei cazurilor de utilizare (fig.
3.14. , pag. 32) .
– Accesul diferitelor categorii de utilizatori este realizată pe baza unei metode de login ,
metodă pe care nu s -a pus accent în cadrul d ezvoltării aplicației , fiind realizată mai
mult pentru a exista o metodă de separare a facilităților diferitelor tipuri de utilizatori .
– Fiind o aplicație dezvoltată pentru mediul de lucru în cadru specializat al unei
companii de producție , aplciația nu dispune de o interfață utilizator prea dezvoltată ,
cum sunt aplicațiile destinate publicului larg . Acest lucru se datorează faptului că în

58
acest mediu se pune accent ul pe funcționalitatea cât mai bună a aplicației în primul
rînd și mai apoi pe aspectul v izual al acesteia .

Proiectarea bazei de date și implementarea simplă poate ajuta la dezvoltarea ulterioară
a aplicației :
– Printre primele dezvoltări care pot fi implementate pe care sistemul informatic realizat
este dezvoltarea capitolului de securit ate și acces diferit la date , capitol pe care nu s -a
pus accent în dezvoltarea aplicației pînă în acest moment .
– Deținînd codul sursă poat fi adăugar te noi condi ții de programare a comenzilor .
– O altă dezvoltare a aplicației poate fi realizată prin includerea unui modul prin care pe
baza unei parole primite la efectuarea comenzii , clienții să poată vizualiza stadiul în
care comanda lor se află .

Fiind o aplicație dezvoltată intr -un timp relativ scurt și de către o singuă persoană ,
aceasta are anumite limite . Una dintre limitările acestui sitem vine datorită lipsei de
experiența în domeniul în care activează acest sistem informatic . Totuși pentru realizarea
acestui software am realizat o documentare a ceea ce înseamna activitatea de gestiu ne și
programarea comenzilor în cadrul unei firme care produce radiatoare de racire pentru mașini .
Astfel programul realizat este propus pentru acest tip de activitate.
Cu mici modificări făcute , sistemul poate fi implementat pentru diferite categorii d e
activități de producție , de la producția de radiatoare pentru mașini (domeniu pentru care este
proiectat în momentul de față ) , până la producția de mobilă sau diferite obiecte minore, dar
care presupu n un proces complex de producție .

59
BIBLIO GRAFIE

[1] Ileana stefan – Analiza și proiectarea sistemelor informatice , Tirgu mures, 2007
[2] Chindea M. E. – Proiectarea sistemelor informatice economice, București, 1999
[3] Dorin Lixandroiu , Radu Lixandroiu – Baze de date relationale , Brasov 2009
[4] Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed. Cison, București 2000
[5] Udrică M. – Modelarea orientată obiect, Ed. Cison, București, 2000
[7] C. J. Date, Baze de Date, Ed. Plus, București, 2002
[8] Visual C# , Lucian Sasu , 2005

[9] http://www.sparxsystems.com.au Site-ul dezvoltatorului aplica ței Enterprise Architect