Sistemul Informatic Pentru Gestiunea Unui Depozit de Materiale de Constructii

LUCRARE DE DIPLOMĂ

SISTEM INFORMATIC PENTRU GESTIUNEA UNUI DEPOZIT DE MATERIALE DE CONSTRUCȚII

CUPRINS

CAPITOLUL I. Introducere

1.1. Scopul Lucrării

1.2. Structura Lucrări

1.3. Sisteme informatice și informaționale. Noțiuni generale

CAPITOLUL II. Cerințele și analiza sistemului informațional

2.1. Specificarea cerințelor

2.2. Analiza sistemului informatic

2.2.1. Analiza bazei de date relaționale. Modelul entitate-relație

2.2.2. Analiza aplicației software. Diagrama Procesului de Afaceri

CAPITOLUL III. Proiectarea sistemului informatic

3.1 Proiectarea bazei de date relaționale

3.2 Proiectarea aplicației software a sistemului informatic

CAPITOLUL IV. Implementarea sistemului informatic

4.1. Implementarea bazei de date

4.2. Implementarea aplicației software a sistemului informatic

4.2.2. Concluzii

BIBLIOGRAFIE

CAPITOLUL I. Introducere

Scopul Lucrării

Prin intermediul acestei lucrari, mi-am propus sa realizez o aplicatie care utilizeaza un sistem informatic de gestiune clienti. In proiectarea sistemului , si pentru optimizarea activitatilor, m-am bazat pe modul de functionare al unui depozit logistic de marfuri tip LIDL, util in controlul aprovizionarii, stocului de marfa si distributiei catre clienti pe o arie mai larga.

Lucrarea își propune să realizeze o aplicație care să ofere un sistem informatic pentru un depozit de materiale de construcții, sistem informatic care se ocupă cu vânzarea de diferite materiale de construcții. Acest sistem informatic are ca scop optimizarea activităților companiei. Sistemul proiectat se va ocupa de gestionarea stocului de materiale și de a gestiona vânzarea de materiale de construcții către clienți.

Sistemul informatic, are o interfata de logare ce permite accesul utilizatorilor in functie de pozitia ierarhica ocupata in cadrul firmei. Acest lucru este necesar pentru atribuirea de diferite responsabilitati care trebuie indeplinite de catre angajati.

Sistemul informatic va permite accesul la informații separat, în funcție de poziția ocupată în cadrul companiei. Fiecare utilizator în funcție de poziția pe care o ocupă în companie are anumite responsabilități de care trebuie să se ocupe.

Aplicatia a fost realizata utilizand cunostintele si informatiile acumulate in perioada studiilor universitare, in special cele care se refera la programare orientata pe obiecte si baze de date. Am utilizat Microsoft SQL Server pentru a crea baza de date a sistemului informatic cu ajutorul limbajului universal SQL si limbajul de programare C# pentru aplicatia propriu-zisa.

Pentru realizarea aplicației am folosit cunoștințele dobândite în anii de studiu, în special cele legate de baze de date și programare orientată pe obiecte. Baza de date a sistemului informatic am creat-o în Microsoft SQL Server cu ajutorul limbajului universal SQL. Aplicația propriu-zisă a sistemului a fost realizată în limbajul de programare C#.

Structura Lucrării

Am structurat lucrarea in 4 capitole, fiecare avand mai multe subcapitole.

Primul capitol contine o introducere care descrie scopul si structura lucrarii,

Lucrarea este organizată pe 4 capitole, fiecare capitol fiind format din mai multe subcapitole.

În primul capitol este prezentată introducerea, care este alcătuită din scopul și structura lucrării dar și noțiuni generale privind sistemele informatice și informaționale.

Al doilea capitol este format din specificarea cerințelor și analiza sistemului informatic. Analiza sistemului informatic cuprinde analiza bazei de date relaționale și analiza aplicației software.

Al treilea capitol este format din proiectarea sistemului informațional care include proiectarea bazei de date relaționale cât și proiectarea aplicației software. În cadrul proiectării software a sistemului informatic sunt prezentate diagramele folosite.

În capitolul patru este prezentată implementarea sistemului informatic care cuprinde implementarea bazei de date cât și implementarea aplicației software precum și formularea concluziilor.

Sisteme informatice și informaționale. Noțiuni generale

Sistemul informațional este ansamblul de elemente implicate în procesul de colectare, transmisie și prelucrare de informații. Rolul sistemului informațional este de a transmite informația între diferite elemente.

Sistemul informațional cuprinde: informația vehiculată, documentele purtătoare de informații, mijloace de comunicare, personalul, etc.

În cadrul acestui sistem se pot desfășura diverse activități precum: centralizarea datelor, achiziționarea de informații din sistemul de bază, etc.

Numeroase activități din sistemul informațional se pot realiza prin intermediul tehnicilor de calcul. Se prelucrează datele primare transferandu-se astfel rezultatul către un alt compartiment de prelucrare. Acest transfer se poate efectua pe cale electronică, prin intermediul modemului sau al unei rețele de calculatoare. Toate aceste elemente prin intermediul cărora se prelucrează și transmit datele pe cale electronică în acest proces, compun un sistem informatic.

Sistemul informatic reprezintă un sistem cu ajutorul căruia se introduc datele prin proceduri manuale sau sistemul le colectază în mod automat, le stochează, le prelucrează după care se extrag rezultatele sub diverse forme. Sistemul informatic poate cuprinde: oameni, date prelucrate, sisteme de transmisie a datelor, calculatoare, diferite componente hardware, software, etc.

Conceptul de sistem este legat de: utilizarea computerelor din domeniul economic, tehnologiile de management-ul informației care dețin un loc important asupra calității, valorii business-ului, etc și rețelele de calculatoare ca elemente componenete ale sistemelor de prelucrare a informațiilor.

Sistemul este format dintr-un grup de componente între care se stabilesc relații și care conlucrează spre un scop comun prin acceptarea de intrări și de ieșiri printr-un proces (de transformare).

.

CAPITOLUL II. Cerințele și analiza sistemului informațional

2.1. Specificarea cerințelor

Sistemul informatic care urmează să fie realizat este executat pentru o societate comercială care se ocupă cu vânzarea de materiale de construcții și care dorește un nou sistem informatic pentru gestionarea comenzilor. Sistemul va putea permite adăugarea de noi produse, înregistrarea clienților, introducerea comenzilor primite de la acești clienți cât și vizualizarea catalogului de produse.

Clienții firmei sunt persoane fizice, iar pentru fiecare client, la introducerea în baza de date, trebuie completat cu un id de client, nume, prenume, adresa și număr de telefon.

Materialele de construcții care se află în baza de date au ca și câmpuri id de material, un număr generat la introducerea în sistem, numele materialului, un id de producător, date tehnice și specificații pentru fiecare produs.

Comenzile sunt identificate după un id unic. Fiecare comandă poate să conțină mai multe tipuri de materiale. Pentru fiecare comandă se înregistrează datele clientului.

Aplicația este dedicată activității interne a societății, utilizatorii ei fiind persoane specializate în domeniul în care activează și sunt repartizați astfel:

Operatorul de marketing are posibilitatea să adauge noi comenzi, să vizualizeze în ce stadiu sunt comenzile și să vizualizeze stocul.

Angajatul are posibilitatea să modifice starea comenzilor, acest lucru permite urmărirea stadiului de realizare a unei comenzi. El mai are posibilitatea să vizualizeze comenzile pe care trebuie să le realizeze, și să vizualizeze detaliile despre material și detaliile despre clienți.

Angajatul responsabil cu aprovizionarea are posibilitatea să vizualizeze stocul, să adauge furnizori, să comande materiale și face recepția la comenzile furnizorilor.

Managerul are dreptul sa vizualizeze stadiul comenzilor, să aprobe comenzile, să adauge furnizori, vizualizează stocul de materiale și să comande materiale.

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 principalelor procese care se regăsesc în ea.

2.2.1. Analiza bazei de date relaționale. 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 dintre ele . Principalele concepte folosite pentru construcția acestei diagrame sunt : entitatea, relația, cardinalitatea, atributul .

Entitatea poate fi un obiect fizic dar și o activitate sau concept. Ea reprezintă clase de obiecte care au proprietăți comune și existență autonomă.

Entitatea este reprezentată printr-un dreptunghi, în cadrul căruia se află numele. Nu pot exista două entități cu același nume, astfel fiecare entitate trebuie să fie denumită în mod unic. Reprezentarea entităților se face întotdeauna prin substantive.

Relația reprezintă o asociere între entități. În schema conceptuală fiecare relație are un nume unic, reprezentat prin verbe.

Atributul este o proprietate care descrie un anumit aspect al unei entități. Atributele prin care este descrisă o entitate se aleg să fie relevante relativ la domeniul de interes pe care se defineste modelul respective.

Cardinalitatea unei relații este specificată pentru fiecare entitate participantă la relație și descrie numărul minim, respectiv maxim de apariții ale relației la care poate participa o apariție a entității.

Există trei tipuri de relații, depinzând de cardinalitățile maxime ale entităților implicate în relație :

Cardinalitate unu-la-unu(1:1) – există o corespondență unu la unu între entități.

Cardinalitate unu-la-mai-mulți(1:N) – cardinalitatea maximă a unei entități este 1, iar cardinalitatea maximă a celeilalte este N:

Fig. 2.1. Cardinalitate 1 la n

Cardinalitate mulți-la-mulți(N:M) – fiecare entitate are cardinalitate maximă (N,M)

Fig. 2.2. Cardinalitate n la m

Diagrama entitate-relație

Diagrama entitate–relație constă în reprezentarea entităților și a relațiilor sistemului, acestea fiind reprezentate cum a fost prezentat mai sus prin entități și relații.

Principalii pași pentru construirea diagramei entitate-relație sunt:

Identificarea entităților care fac parte din sistem

Identificarea tipurilor de relații

Desenarea diagramei entitate-relație

Fig. 2.3. Diagrama Entitate – Relație

2.2.2. Analiza aplicației software. Diagrama Procesului de Afaceri

După ce am terminat analiza bazei de date relaționale, următorul pas constă în analizarea aplicației software pentru sistemul informatic descris în cerințe. Aplicația software trebuie să se folosească 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 procese . Această analiză poate fi realizată cu ajutorul diagramei procesului de afaceri (Business Process Model ) .

Diagrama procesului de afaceri (Business Process Model)

Este diagrama care descrie în mare vocabularul afacerii pentru care urmează să fie implementat sistemul informatic . Reprezintă punctul de pornire în proiectarea acestui tip de 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 informatic care trebuie creat .

Un proces de afacere este o colecție de activitați care sunt menite să producă un anumit rezultat . Reprezintă o vedere puternică asupra cum este realizată intr-o companie , în contrast cu vederea pe care 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 mare vocabularul afacerii pentru care urmează să fie implementat sistemul informatic . Reprezintă punctul de pornire în proiectarea acestui tip de 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 informatic care trebuie creat .

Un proces de afacere este o colecție de activitați care sunt menite să producă un anumit rezultat . Reprezintă o vedere puternică asupra cum este realizată intr-o companie , în contrast cu vederea pe care 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 considerate ca o structură pe care aplicația software pentru sistemul informatic se bazează .

Principalele componente ale unei astfel de diagrame sunt : actorii, evenimentul care declanșează procesul, procesul, scopul procesului, informațiile auxiliare, resursele necesare procesului și 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 cu acesta . Grafic ei sunt reprezentați sub forma unor mici personaje având propriul său nume.

Fig. 2.4. Reprezentare grafică actor

Evenimentul care declanșeaza procesul

Este evenimentul care duce la startul procesului , și este de cele mai multe ori un eveniment declanșat de către un actor . În cadrul diagramei este reprezentat ca un eveniment public , care este descris printr-un verb.

Fig. 2.5. Eveniment declanșator

Procesul

Un proces reprezintă o activitate care are un scop 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 îngroșate , iar denumirea procesului este încapsulată în cadrul acestei reprezentări .

Fig. 2.6. Reprezentare proces

Scopul Procesului

Scopul procesului reprezintă cauza pentru care sistemul funcționează și trebuie să fie exprimat în cei mai potriviți termenii care arată modul în care acest proces aduce beneficii. Scopul se află reprezentat în dreptunghiul de mai jos și este conectat de căsuța de proces printr-o linie discontinuă.

Fig. 2.7. Reprezentare scop

Informații auxiliare

Pentru a-și îndeplinii scopul, procesele folosesc informații care spre deosebire de resurse, nu sunt consumate în cadrul acestuia. Informațiile pot rezulta din diferite surse ca de exemplu, catalog produse este considerat ca fiind o informație auxiliară procesului de gestiune a comenzilor. Informațiile auxiliare și procesul sunt reprezentate prin căsuțe care sunt legate între ele cu ajutorul unor săgeți întrerupte cu textul supply.

Fig. 2.8. Reprezentare informație auxiliară

Resurse necesare procesului

Resursele sunt date de intrare în proces care sunt modificate și consumate pe parcursul întregului proces. Ele sunt reprezentate prin căsuțe care sunt conectate de proces cu ajutorul unor săgeți întrerupte cu textul input.

Fig. 2.9. Reprezentare resurse necesare

Rezultatul procesului

Informațiile și acțiunile reprezintă rezultatul procesului după terminarea acestuia. Informațiile și acțiunile sunt reprezentate printr-o căsuță unde apar denumirile obiectelor care rezultă din acest proces.

Fig. 2.10. Reprezentare rezultat proces

În continuare am reprezentat Diagrama Procesului de Afacere utilizând elementele de mai sus.

Fig. 2.11. Diagrama procesului de afacere

CAPITOLUL III. Proiectarea sistemului informatic

În acest stadiu de dezvoltare a sistemului informatic este prezentată partea de proiectare a sistemului punându-se baza pe arhitectura și design-ul acestuia. Design-ul specifică modul în care sistemul își atinge scopul, acesta fiind format din trei activități și anume design-ul interfeței cu utilizatorul, datele utilizate și procesul.

Proiectarea sistemului informatic se realizează în două etape și anume:

Proiectarea bazei de date relaționale: se urmărește descrierea atributelor entităților și explicitarea legăturilor dintre ele.

Proiectarea aplicației software urmărește stabilirea arhitecturii software a sistemului informatic.

În proiectarea bazei de date una dintre cele mai bune strategii este o abordare structurată formată din trei etape:

Proiectarea conceptuală

Proiectarea logică

Proiectarea fizică

3.1 Proiectarea bazei de date relaționale

Baza de date relațională este una dintre cele mai eficiente, modelul relațional fiind cel clasic, în care datele sunt memorate în tabele. Pe lângă acestea, o bază de date poate să conțină utilizatori, tipuri de date, proceduri și funcții, etc.

În etapa de proiectare conceptuală a bazei de date se realizează schema conceptuală și schemele externe ale bazei de date.

Schema conceptuală este rezultatul reprezentării cerințelor informale ale aplicației în termenii descrierii complete, dar care nu este legat de criteriul utilizat pentru reprezentare în sistemul de organizare a bazei de date. Aceasta efectuează o reprezentare a bazei de date, având o formă rapidă și simplu de realizat, prin identificarea datelor și reprezentarea acestora într-o diagramă Entitate-Relație.

Modelul Entitate-Relație este un model conceptual care definește entitățile și asocierile dintre ele, dar nu impune niciun mod specific de structurare și prelucrare a datelor.

Entitatea se referă la un aspect al realității obiective care poate fi deosebit de restul Universului și poate reprezenta o activitate, un obiect, etc.

Aceste model are ca și elemente principale concepte cum ar fi : entitate, relație, atribut, cardinalitate.

Entitățile reprezintă clase de obiecte care care au proprietăți comune și existență autonomă. Entitatea poate fi un obiect fizic precum persoană sau loc, dar și o activitate, sau un concept.

Conceptele transformării sunt:

Entitatea devine un tabel

Se aplică o relație printr-o pereche de chei primară-externă sau printr-un tabel;

Un atribut al unei entități devine denumirea unei coloane din tabel.

Cheia unei entități

Cheia unei entități reprezintă un atribut sau set de atribute care pot identifica în mod unic o instanță a acelei entități. Acestea pot fi de două feluri:

Entități naturale

Entități artificiale (nu au semnificație reală)

Cheile relaționale sunt împățite în:

Cheie străină care identifică o coloană sau mai multe coloane într-un tabel, acesta efectuând o referință la una sau mai multe coloane din alt tabel.

Super cheia reprezintă o coloană sau mai multe coloane care permite identificarea fiecărei înregistrări dintr-un tabel. Trebuie selectate acele super chei care au nevoie de un minimum de coloade pentru identificare unică

Cheia candidată este o super cheie care are numărul minim posibil de coloane necesare pentru o identificare a înregistrărilor. Pot exista mai multe chei candidate.

O cheie candidată trebuie să respecte următoarele condiții:

Să se asigure că fiecare înregistrare este unică

Cheia cadidată este ireductibilă, adică nu se mai asigură că înregistrările sunt unice de nici un sub-set de coloane ale cheii candidate.

Cheia primară este o cheie candidat, care are scopul de a identifica instanțele din cadrul unei relații

În continuare este prezentată Diagrama logică a bazei de date:

Fig. 3.1. Diagrama logică a bazei de date

Tabele asociate diagramei sunt :

PRODUCATOR (id_producator, nume_producator, adresa, telefon, fax, descriere)

FURNIZOR (id_furnizor, nume_furnizor, is_Active )

FURNIZOR _MATERIAL( id_material, id_furnizor, pret)

COMANDA ( id_comanda, id_furnizor, id_material, data_comanda, cantitate,pret,is_Done)

NIR ( id_NIR, id_comanda, id_material, cantitate, pret, data_receptie )

UM ( id_UM, nume_UM)

MATERIAL_UM ( id_material, id_UM, UM_unitate)

MATERIAL ( id_material, nume_material, id_producator, id_tip_material, id_UM, pret_um)

STOC (id_material, cantitate, cantitate_comandata)

CATEGORIE_MATERIALE (id_categorie, nume_categorie)

TIP_MATERIALE (id_tip_material, nume_tip_material, descriere, id_categorie)

CLIENTI (id_client, nume_client, adresa, telefon)

COMANDA CLIENT (id_comanda, id_client, data_comanda, detalii comanda, stadiu, data_update)

DETALII COMANDA ( id_comanda, id_material, cantitate, pret)

3.2 Proiectarea aplicației software a sistemului informatic

În acest proces de proiectare a sistemului informatic este necesară descrierea comportamentului și interacțiunilor care au loc între diferite entități. Acest proces este distribuit pe etape care ajută la anticiparea și pregătirea sistemului pentru a face față situațiilor pe care acesta le-ar putea întâlni în perioada de funcționare.

Diagramele necesare proiectării sunt:

Diagrama Fluxurilor de Date ( Data Flow Diagram).

Diagrama de Activitate (Activity Diagram)

Diagrama Cazurilor de Utilizare (Use Case Diagram)

Diagrama de Stare de Tranziție (State Machine Diagram)

Diagrama de Secvențe (Sequence Diagram)

Diagrama fluxurilor de date

Diagrama fluxurilor de date reprezintă o modelare logică a fluxurilor de date în cadrul sistemului informatic, ceea ce ajută la evidențierea legăturii logice dintre limitele sistemului informatic, a proceselor din interiorul său și a principalelor entități de date.

Diagramele de acest fel sunt construite, în principal, din obiecte care sunt reprezentate în raport cu procedurile aplicației, fără afișarea 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.

Această diagramă reprezintă o metodă foarte bună de rezumare și organizare a informațiilor detaliate despre limitele sistemului informatic, a proceselor, a entităților implicate, oferind proiectantului o hartă a sistemului informatic. Diagrama are ca obiectiv urmărirea modului de transfer al datelor între procesele care le prelucrează.

Scopul diagramelor 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ă unele aspecte ca: sursa datelor de prelucrare, destinația datelor prelucrate, operațiunile de prelucrare și legătura existentă între aceste prelucrări și activitatea de stocare a datelor.

Regulile întocmirii unei diagrame:

Botezarea componentelor și a fluxurilor de date: Proceselor li se asociază la denumirea cât mai sugestivă verbe, a principalelor entități care interacționează cu sistemul informatic și obiectelor lor pentru stocarea datelor sunt asociate substantive ca și fluxurile de date, exprimate tot prin substantive.

Numerotatea proceselor: pentru a putea fi identificate ușor, acestea sunt numerotate secvențial.

Duplicarea entităților externe: Se realizează pentru a nu apărea confuzii în citirea diagramei.

Plasamentul entităților și a stocurilor de date: se încearcă plasarea entităților pe marginea diagramei, iar a stocurilor de date cât mai pe centru.

Fluxurile de date: cele către stocurile de date sunt întotdeauna unidirecționale.

Există simboluri care se folosesc la construcția diagramei de flux de date precum:

Proces : sunt etichetate cu text care arată modul lor de prelucrare a datelor.

Flux de date : format din date care circulă în sistemul informatic.

Entitatea externă : reprezintă o sursă sau receptor de date

Stoc de date : este un depozit de date temporar sau permanent

Fig. 3.2. Diagrama fluxurilor de date

Diagrama cazurilor de utilizare

O diagramă a cazurilor de utilizare este o colecție de cazuri de utilizare și actori care oferă o descriere generală a modului în care va fi utilizat sistemul, arată cum interacționează sistemul cu unul sau mai mulți actori și asigură că sistemul va produce ceea ce s-a dorit.

Diagrama cazurilor de utilizare se creează la începutul procesului de dezvoltare dar mai este folosit și în partea de proiectare a sistemului.

Diagrama cazurilor de utilizare conține:

Actori;

Relații între actori;

Cazuri de utilizare;

Relații între cazurile de utilizare;

Relațiile între actori și cazurile de utilizare;

Actorii

Actorii reprezintă orice element care interacționează cu sistemul, dar nu sunt parte din sistem. Actorii pot primii date și să transmită informații sistemului fără ca să participe la prelucrări. Rolul actorilor este de a interacționa cu sistemul analizat. Reprezentarea grafică în format UML a unui actor este prezentat in figura de mai jos.

Fig. 3.3. Reprezentare grafică actor

Pentru a putea identifica actorii dintr-un sistem trebuie să cunoaștem domeniul problemei cu ajutorul utlizatorilor și analiștilor. Întrebările urmatoare ne-ar putea ajuta să identificăm actorii din sistem:

Care sunt intrările sau ieșirile de care este nevoie în sistem?

Cine este interesat de o anumită cerință?

Unde ar trebui folosit sistemul?

Cu ce alte sisteme va interacționa?

Cine va administra și întreține sistemul?

Cine va furniza sistemului date?

Cine va folosi și va șterge din sistem date?

Cazurile de utilizare

Un caz de utilizare reprezintă o colecție de scenarii posibile, referitoare la comunicarea între sistem și actorii externi, caracterizate de anumite scopuri.O caracteristică importantă a cazurilor de utilizare este că ele arată ce trebuie să facă sistemul și nu cum trebuie să facă.

Reprezentarea grafică a unui caz de utilizare este :

Fig. 3.4. Reprezentare grafică caz de utilizare

Pentru a putea identifica cu ușurință cazurile de utilizare, în primul rând trebuie să identificăm actorii, iar pentru fiecare actor sunt puse următoarele întrebări:

Ce funcționalități ale sistemului va trebui să acceseze actorul?

Poate actorul să lucreze mai eficient dacă folosește noi funcționalități?

Sunt evenimente în sistem care trebuie să îi fie aduse la cunoștință actorului?

Relațiile între actori și cazurile de utilizare

Relațiile între actori și cazurile de utilizare sunt relații de comunicare. Ca și caracateristici ele sunt relațiile cele mai generale și sunt unidirecționale.

Fig. 3.5. Reprezentare grafică relația între actori

Relațiile între actori

Relațiile între actori pot fi relații de generalizare, asta înseamnă că dacă un actor moștenește un alt actor atunci el poate să comunice ca și părinte cu aceleași cazuri de utilizare ale sistemului.

Relațiile între cazurile de utilizare

Relațiile între cazurile de utilizare pot fi de generalizare, extindere sau includere.

Relațiile de generalizare sunt folosite pentru a arăta faptul că un caz de utilizare moștenește comportamentul altui caz și îl îmbunătățește pe acesta.

Relațiile de extindere sunt folosite pentru a arăta că un caz de utilizare este inserat în alt caz.

Relațiile de includere sunt folosite atunci când un caz de utilizare include comportamentul altui caz de utilizare.

Fig. 3.6. Reprezentare grafică relația de includere

Prezentarea diagramei cazurilor de utilizare

În Fig. 3.7. este prezentată diagrama cazurilor de utilizare a sistemului informatic:

Angajat Vânzări este actorul care se ocupă de adăugarea de noi comenzi venite de la clienți. El mai are posibilitatea de a vizualiza comenzile și stocul de material.

Angajat Aprovizionare este actorul care se ocupă cu adăugarea de furnizori, comandă materialele și are posibilitatea să vizualizeze detaliile despre materiale. Pe lângă acestea el se mai ocupă și de recepția comenzilor de la furnizori.

Angajat Necalificat este actorul care se ocupă să modifice starea comenzilor și mai are posibilitatea să vizualizeze detalii legate de clienți și detalii legate de comenzi.

Manager este actorul responsabil să adauge noi materiale, să aduge noi furnizori, să comande materiale și are posibilitatea să vizualizeze stocul de materiale și comenzile.

Adaugă noi comenzi : este un caz de utilizare care presupune introducerea datelor care corespund unei noi comenzi .

Adaugă furnizori este un caz de utilizare care presupune adăugarea de noi furnizori în baza de date.

Adaugă material nou este un caz de utilizare care presupune adăugarea de noi materiale în baza de date.

Comandă material este un caz de utilizare care presupune efectuarea unei noi comenzi pentru material.

Diagrama de activitate

Diagrama de activitate cuprinde toate atributele unei diagrame de stare, însă are și alte atribute noi. Prin această metodă se poate vedea ceea ce se întâmplă în cadrul unui caz de utilizare, sau al unui process ce se desfășoară în sistemul informatic. Această diagramă este folosită pentru a modela dinamica unui proces sau a unei operații și reprezintă fluxul de control de la o activitate la alta.

Componentele principale ale diagramei de activitate sunt:

stări de acțiune și stări de activități

tranziții

obiecte

bare de sincronizare

ramificații

Stările de acțiuni reprezintă execuția propriu-zisă a unei acțiuni și nu poate fi descompusă. Ele sunt atomice, nu pot fi întrerupte indiferent dacă se produc sau nu evenimente și au o durată foarte mică. În cadrul unei activități există o singură acțiune inițială, una sau mai multe acțiuni simple și finale.

Stările de activități sunt procesări neatomice adică pot fi întrerupte la apariția unui eveniment, ele putând fi descompuse, iar activitatea lor se poate reprezenta prin alte diagrame de activități.

O stare de activitate se reprezintă grafic:

Fig. 3.8. Reprezentare grafică a unei stări de activitate

Punctul inițial reprezintă locul de pornire în citirea secvenței de acțiuni care formează 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.

Un punct inițial este reprezentat grafic:

Fig. 3.9. Reprezentare grafică punct inițial

Punctul final reprezintă ultima acțiune dintr-o diagramă de activitate, iar în modelarea UML se reprezintă prin cercuri mici concentrice, din care cel interior este plin. Spre deosebire de punctul inițial, o activitate poate avea mai multe puncte de final.

Un punct final este reprezentat grafic:

Fig. 3.10 Reprezentare grafică punct final

Tranzițiile într-o diagramă de activitate arată întotdeauna ordinea de execuție a acțiunilor. Ele sunt reprezentate sub forma unei săgeți care întotdeauna arată către acțiunea care urmează să se execute.

Tranziția este reprezentată grafic în figura de mai jos:

Fig. 3.11. Reprezentare grafică tranziție

Obiecte

O acțiune este realizată de către un obiect, sau operează asupra unui obiect, acesta putând interveni în diagramă în două moduri :

operația unui obiect este considerată numele activității

obiectul poate fi privit ca intrare sau ieșire a unei activități

Bare de sincronizare sunt de două tipuri și anume join (îmbinare) sau fork (bifurcare). În timpul execuției mai multor activități, există posibilitatea ca acestea să se execute în paralel, iar pentru sincronizarea acestor activități se folosesc aceste bare de sincronizare.

Ramificațiile sau blocuri de decizie sunt folosite pentru modelarea alternativelor, a căror alegere depinde de o expresie booleană. Acestea au o tranziție de intrare și două sau mai multe tranziții de ieșire, fiecare tranziție de ieșire fiind etichetată cu o condiție de gardă, condiție care trebuie să acopere toate posibilitățile de continuare a execuției și să nu se suprapună.

Una dintre cele mai importante activități este Activitatea de introducere a comenzilor furnizor. Introducerea propriu-zisă se face de către Operatorul de Marketing pe baza cerințelor exprimate de către client . Această activitate presupune executarea acțiunilor de logare , introducera datelor clientului , vizualizarea catalogului de produse , selectarea produselor , adăugarea numărului de produse dorite , și adăugarea comenzii în baza de date .

Diagrama este reprezentată în figura de mai jos:

O altă diagramă importantă este Diagrama de activitate pentru adăugarea de materiale de construcții. Această activitate este realizată de către Manager. Acțiunile derulate în cadrul activității sunt acțiunile de logare , adăugare material, selectarea sau adăugarea de câmpuri necesare și salvarea datelor. În diagramă avem două puncte de decizie, primul punct este situate după acțiunea de logare, iar dacă logarea nu s-a efectuat cu succes se realizeaza terminarea activității. Al doilea punct de decizie este situate după acțiunea de selectare/ adugare de câmpuri necesare.

Diagrama de activitate pentru adăugarea de material este reprezentată:

Fig. 3.13. Diagrama de activitate pentru Adăugarea unui material

Diagrama tranzițiilor de stare

Diagrama de stare a tranzițiilor reprezintă stările unei clase date, evenimentele ce cauzează tranzițiile de la o stare la alta și acțiunile care rezultă din schimbările stărilor.

Scopul acestor diagrame este de a descrie răspunsul și comportarea diferitelor 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.

Într-o stare, toate acțiunile care există trebuie să se afle în următoarele momente: on entry, on exit, on an event, upon event.

Starea este reprezentată grafic printr-un dreptunghi, în interiorul căruia scriem numele și un compartiment. Componentele principale ale unei diagrame de tranziții sunt: stările, tranzițiile, punctele de decizie, punctele de intrare și ieșire.

O diagramă poate să prezinte mai multe stări, dintre care doar una poate fi stare de intrare, restul fiind stări imbricate și finale.

Tipuri de stări

Starea inițială reprezintă inițializarea mașinii cu stări, conectându-se mașinii de stări printr-o tranziție neetichetată. Această stare este unică într-o diagramă de stare.

Stările imbricate au apărut atunci când într-o diagramă de stări, numărul de conexiuni dintre stări devine ridicat.

Starea finală reprezintă starea terminală a unui sistem și este folosită în cadrul diagramei de stare când se dorește explicitarea finalului mașinii de stare.

Tranziția este trecerea de la o stare la altă stare și poate fi folosită 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 care pot fi trecute , opțional acțiunile care au loc pe parcursul tranzițiilor.

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.

Stările prin care trece sistemul informatic în momentul în care se execută procesul de adăugare a comenzilor venite de la clienți încep cu verificarea existenței clientului în baza de date, dacă clientul există în sistem atunci se înregistrează datele referitoare la comandă, se continuă cu starea în care sunt selectate materialele iar apoi urmează un punct de decizie.

Din punctul de decizie se poate reveni în starea în care înregistrează datele despre comandă altfel se trece în starea în care comanda este finalizată, stare care este și starea finață a sistemului.

În figura de mai jos se poate observa această diagrama de stare a tranzițiilor pentru sistemul informatic , în momentul introducerii unei noi comenzi venite de la clienți.

Fig. 3.14. Diagrama de stare a tranzițiilor

Diagrama de secvențe

Diagrama de secvențe reprezintă grafic o interacțiune între obiecte insistând în ordinea temporală a expedierii mesajelor. Perioada în care un obiect preia controlul sau efectuează o acțiune , este reprezentată sub forma unui dreptunghi în dreptul linie punctate .

Scopul unei astfel de diagrame este de a creea o idee asupra cum preiau obiectele acțiunea în anumite situații și asupra modului în care acestea se comportă și interacționează între ele , toate aceste lucruri fiind analizate având în vedere caracteristica cronologică și a timpului în care acestea îsi desfășoară activitatea .

Într-o diagramă de secvență, elementele de bază sunt obiectele, liniile de viață și mesajele.

Obiectele sunt principalele elemente ale diagramei, sunt entitățile care în cadrul diagramei intervin în preluarea datelor, prin transmisia și recepționarea de mesaje. Ele sunt reprezentate grafic prin dreptunghiuri în cadrul cărora sunt scrise numele.

Liniile de viață reprezintă axa timpului pentru diagrame, astfel cronologia expedierii mesajelor fiind redată de apariția lor pe axe. Ele sunt reprezentate printr-o linie verticală punctată, fiecare obiect având o astfel de linie.

Mesajele sunt elementele cu care obiectele comunică între ele. Ele sunt reprezentate sub forma unor săgeți care unesc liniile de viață ale obiectelor. După modul în care se face preluarea datelor, mesajele se clasifică în trei categorii: mesaje sincrone, mesaje asincrone și mesaje simple.

Mesajele sincrone sunt mesajele după care se așteaptă terminarea completă a preluării indicate de către acesta.

Mesajele asincrone sunt opusul mesajelor sincrone și arată că se poate începe și realiza o nouă prelucrare chiar dacă nu s-a finalizat prelucrarea în curs.

Mesajele simple sunt mesajele pentru care nu sunt este specificat faptul dacă sunt sincrone sau asincrone.

În această parte a proiectării sistemului informatic 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 operațiile care au loc între clase.

În figura de mai jos(Fig.3.15) este prezentată diagrama de secvențe:

Fig. 3.15. Diagrama de secvențe

După cum se poate observa din cadrul diagramei prezentată mai sus ( fig) se poate distinge faptul că fiecare obiect nou al clasei Comandă trece prin următoarele secvențe de activitate:

Angajat Vânzări introduce o comandă nouă în sistem

Se preia comanda de către angajat

Angajatul necalificat verifică stocul de materiale

Dacă stocul este ok , se pregătesc materialele

După ce s-au pregătit materialele, se face livrarea comenzii.

CAPITOLUL IV. Implementarea sistemului informatic

Implementarea propriu-zisă a sistemului informatic este ultima parte din realizarea sistemului informatic și presupune traducerea algoritmului din faza de proiectare în limbajul de programare ales pentru dezvoltarea aplicației. Implementarea sistemului informatic proiectat se realizează în două etape și anume:

Implementarea bazei de date

Implementarea aplicației software

4.1. Implementarea bazei de date

Această etapă din realizarea sistemelor informatice constă în realizarea proiectării fizice a bazei de date și presupune transformarea designului logic al bazei de date, într-o structură fizică eficientă, specifică pentru sistemul de gestiune al bazei de date folosit.

Limbajul SQL

În prezent limbajul SQL este un limbaj folosit pentru crearea, modificarea, regăsirea și manipularea datelor de către bazele de date relaționale. Implementarea limbajului SQL se poate face prin 3 metode prin care acest lucru se poate realiza apelarea directă care constă în introducerea instrucțiunilor direct din prompter, apelarea modulară care folosește procedeuri apelate de programele aplicației și apelarea încapsulată care conține instrucțiuni încapsulate în codul de program.

Instrucțiunile limbajului SQL sunt grupate în mai multe categorii și anume: instrucțiuni de definire a datelor , instrucțiuni de manipulare a datelor , instrucțiuni de selecție a datelor , instrucțiuni de control a datelor.

Microsoft SQL Server

SQL Server a fost lansat în anul 1989 și a devenit unul dintre cele mai importante sisteme de gestiune a bazelor de date prezente pe piață în zilele noastre.

Principalele caracteristici ale aplicației SQL Server sunt:

Utilizarea este mai ușoară deoarece are un model de programare asemănător celui al Windows-ului.

Instalarea se face cu ușurință deasemenea și utilizarea și dezoltarea de aplicații.

Permite lucrul cu documentele XML

Poate fi integrat cu alte produse software

Procesul de interogare poate fi împărțit în mai multe părți, fiecare fiind executată de către un alt procesor.

Elemente ale limbajului SQL în cadrul SQL Server

În SQL există trei categorii de comenzi și anume prima comandă este pentru crearea structurii de bază de date, a doua comandă este cea pentru adăugarea și manipularea a datelor în tabele după crearea structurii și a treia comandă este pentru securizarea datelor.

Comenzile pentru crearea structurii bazei de date sunt: Create, Alter, Drop.

Comenzile pentru manipularea datelor sunt: Insert, Update, Delete, Select.

Comenzile de control sunt: Grant, Revoke.

După implementarea sistemului informatic, au rezultat un număr de 14 tabele, fiecare tabel având atribute corespunzătoare pentru datele care sunt stocate în acel tabel.

Fig. 4.1. Reprezentarea unei tabele

Manipularea datelor din baza de date este realizată cu ajutor de proceduri stocate, cu ajutorul lor putând fiind realizate operații specifice de manipulare: Select, Delete, Update și Insert.

În urma implementarii au rezultat 45 de proceduri stocate. Structura unei proceduri stocate conține numele acesteia, eventual parametrii transmiși și operațiile care se execută în cadrul procedurii.

Fig. 4.2. Exemplu de procedură stocată: extragere categorie materiale după id

4.2. Implementarea aplicației software a sistemului informatic

Pentru a implementa o aplicație software se disting 3 nivele de implementare:

Nivelul Prezentare este reprezentat de către interfața utilizatorilor.

Nivelul Logic este codul din spatele interfeței și care face ca programul să funcționeze corect.

Nivelul Acces la date are rolul de stocare a datelor utilizate de către program.

4.2.1 Limbajul C#

Limbajul C# este unul dintre cele mai utilizate limbaje de programare în dezvoltarea sistemelor informatice fiind realizat de către cei de la Microsoft. Are ca principii elementele fundamentale din programarea orientată pe obiecte și ca și principiu de utilizarea moștenește sintaxa și principiile de programare din C++.

Pentru a realiza o aplicație C# sunt folosite mai multe clase, fiecare clasă fiind grupată în namespaces, acestea cuprinzând mai multe clase cu nume diferite având funcționalități înrudite. Două clase pot avea același nume cu condiția ca ele să fie definite în spații de nume diferite . O clasă este formată din date și metode, apelarea unei metode în cadrul clasei

în care a fost definită aceasta presupunând specificarea numelui metodei.

Prezentarea aplicației realizate cu limbajul C#

Aplicația software a sistemului informatic dezovoltat, este o aplicație care conține mai multe nivele logice. Aceste nivele sunt: nivelul de acces la date, nivelul de manipulare a obiectelor și a operațiilor specifice sistemului informatic, nivelul de prezentare.

Nivelul de acces la date reprezintă nivelul în care se face conexiunea la baza de date. Acest nivel este reprezentat în sistemul informatic propriu-zis de către un connectionstring cu ajutorul căruia se face conectarea la baza de date.

Fig. 4.3. Exemplu ConnectionString

Nivelul de manipulare a obiectelor și a operațiilor specifice sistemului informatic

Pentru manipularea datelor din baza de date am realizat o mapare a acesteia cu ajutorul unor clase de obiecte, câte una pentru fiecare tabel din baza de date, cu același nume și atribute ca și tabelul respectiv.

Fig. 4.4. Maparea stocului de materiale

Manipularea datelor obținute în urma interogărilor în baza de date se face cu ajutorul unor metode deasemenea specifice pentru fiecare tabel, metode care sunt apelate în program ori de câte ori este nevoie de date din acel tabel.

Fig. 4.5. Funcția care ia stocul unui material după id material

Nivelul de prezentare reprezintă nivelul de interfață grafică al aceste aplicații, iar pentru implementarea lui s-au folosit elemente specifice de interfață grafică din Visual C#, de exemplu comboBox-uri, TextBox-uri, Form-uri, etc.

4.2.2. Concluzii

Aplicația Sistem informatic de gestiune a unui depozit de materiale de construcții a fost proiectată pentru a gestiona și programa eficient comenzile unui depozit care se ocupă cu vânzarea de materiale de construcții.

Caracteristicile principale ale sistemului informatic sunt:

Sistemul este proiectat să se ocupe doar de partea de programare pentru a gestiona vânzarea de materiale către clienți și de a gestiona stocul de materiale.

Activitățile economice sau de gestiune a personalului sunt ignorate în acestă aplicație.

În funcție de poziția ocupată în sistem, fiecare utilizator are acces separat la informații. Funțiile sunt definite în diagrama cazurilor de utilizare.

În această aplicație s-a pus baza pe funcționalitatea cât mai bună a acesteia iar interfața utilizator nu este prea dezvoltată.

Pe viitor pentru dezvoltarea aplicației se poate dezvolta securitatea datelor și accesul diferit la date, deoarece nu s-a pus accent pe acest lucru.

Ținând cont de perioada scurtă de timp în care a fost realizată aplicația, aceasta nu este foarte complexă. Se pot îmbunătății anumite informații de care utilizatorul are nevoie, ceea ce a fost proiectat și implementat în cadrul aplicației fiind doar un punct de dezvoltare pentru noi funcționalități.

Deținând codul sursă, pot fi adăugate noi condiții de programare a comenzilor.

Aplicația are anumite limite și anume una din aceste limite este lipsa de experiență în acest domeniu dar totuși am realizat o documentare a ceea ce înseamnă activitatea de gestiune a unui depozit de materiale de construcții.

BIBLIOGRAFIE

[1] Bocu. D., Bocu. R. – Modelare orientată obiect cu UML, Ed. Albastră, Cluj-Napoca, 2007

[2] C. J. Date, Baze de Date, Ed. Plus, București, 2002

[3] Florescu V., P.Nastase, F.Berbec – Baze de date – fundamente teoretice si practice, Editura Infomega, Bucuresti, 2002;

[4] Lixandroiu Dorin , Radu Lixandroiu – Baze de date relationale , Brasov 2009

[5] Mocian I. – Baze de date-pentru uzul studenților, Ed.Universității “Petru Maior”, Târgu-Mureș, 2008

[6] Onete B. Sisteme informatice, Editura A.S.E București, București, 2000

[7] Roșca I., – Proiectarea sistemelor informatice financiar contabile, Ed.Didactică și Pedagogică, București, 1993

[8] Sasu L. – Visual C#, 2005

[9] Ștefan Ileana– Analiza și proiectarea sistemelor informatice , Tirgu mures, 2007

[10] Udrică M. – Modelarea orientată obiect, Ed. Cison, București, 2000

[11] http://ro.wikipedia.org/wiki/SQL

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

[13] http://www.scritube.com/stiinta/informatica/sql/Limbajul-SQL65389.php

BIBLIOGRAFIE

[1] Bocu. D., Bocu. R. – Modelare orientată obiect cu UML, Ed. Albastră, Cluj-Napoca, 2007

[2] C. J. Date, Baze de Date, Ed. Plus, București, 2002

[3] Florescu V., P.Nastase, F.Berbec – Baze de date – fundamente teoretice si practice, Editura Infomega, Bucuresti, 2002;

[4] Lixandroiu Dorin , Radu Lixandroiu – Baze de date relationale , Brasov 2009

[5] Mocian I. – Baze de date-pentru uzul studenților, Ed.Universității “Petru Maior”, Târgu-Mureș, 2008

[6] Onete B. Sisteme informatice, Editura A.S.E București, București, 2000

[7] Roșca I., – Proiectarea sistemelor informatice financiar contabile, Ed.Didactică și Pedagogică, București, 1993

[8] Sasu L. – Visual C#, 2005

[9] Ștefan Ileana– Analiza și proiectarea sistemelor informatice , Tirgu mures, 2007

[10] Udrică M. – Modelarea orientată obiect, Ed. Cison, București, 2000

[11] http://ro.wikipedia.org/wiki/SQL

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

[13] http://www.scritube.com/stiinta/informatica/sql/Limbajul-SQL65389.php