Sistem Informatic Pentru Gestiunea Vanzarilor la O Tipografie

Sistem Informatic Pentru Gestiunea Vanzarilor la O Tipografie

Byadmin ianuarie 1, 2024

CAPITOLUL I. INTRODUCERE

1.1. Sistem informatic și Sistem informational. Noțiuni Generale

Calculatoarele au un rol important în societatea de astazi, acesta prelucrând o serie de informații care i se oferă. Veriga esentială în acest context este informația. Sisteme informatice și sisteme informaționale sunt cele doua concepte întalnite în practică.

Sistemul informațional este definit ca ansamblul de mijloace (tehnice, umane, financiare etc) implicate în procesul de colectare, transmisie si prelucrarea de informații. Informatia circulă în interiorul sistemului informațional. Ca exemplu, managerii unei instituții financiar-bancare pot folosi informațiile furnizate de un sistem informațional pentru a lua diferite decizii.

Componentele sistemului informațional sunt urmatoarele:

mijloace de comunicare;

sisteme de prelucrare a informației

personalul;

informația vehiculata;

documentele purtătoare de informații etc.

Rolul sistemului informațional :

centralizarea datelor;

completarea documentelor și transferul acestora între diferite

compartimente;

achiziționarea de informații din sistemul de bază etc.

Sistemului informațional este alcătuit din:

componenta pentru stocarea (memorarea informațiilor);

componenta pentru prelucrarea informațiilor.

Sistemul informațional este folosit pentru:

conlucrarea cu sistemele operaționale și decizionale, dar și cu sistemele din mediul extern pentru adunarea de informații;

stocarea informațiilor și prelucrarea lor;

asigurarea accesului la memorie în vederea transmiterii informațiilor stocate;

prelucrarea informațiilor la cererea sistemului operațional și a sistemului de conducere;

Într-o organizație, activitățile de la nivel operațional și de management, folosesc informații furnizate de un sistem informatic. Acesta, fiind un sistem utilizator – calculator, foloseste echipamente hardware și produse software, precum si o bază de date și modele matematice pentru luarea deciziilor, analiză, planificare sau control.

Pentru prezentarea cât mai sugestivă a realității din componența sistemului informațional, în crearea sistemelor informatice se impune formalizarea modelării sistemului informațional. Un sistem informatic complex are mai multe nivele. Poate fi descompus pe subsisteme, apoi pe aplicatii destinate diferitelor categorii de utilizatori. Aplicațiile, la rândul lor, pot fi constituite din unul sau mai multe programe, scrise în diverse limbaje de programare.

Fig.1.1. Sistem informatic, subsisteme, aplicații, programe

În schimb, pentru o organizație de talie mică, sistemul informatic poate fi reprezentat de o singură aplicație, realizându-se astfel informatizarea activității.

Sistemele, subsistemele și aplicațiile informatice intră în categoria de produse software.

Pentru a obține informații si a fundamenta decizii în mod automat, în domeniul economic se va folosi un sistem informatic economic care interconectează ansamblul componentelor sistemului economic. Atât timp cât unele activități din procesul decizional nu pot fi automatizate, sistemul informațional va include si sistemul informatic. Orice sistem informatic poate fii descris în funcție de rolul său de bază, și anume obtinerea de informații pentru fundamentarea luării deciziilor la nivel de conducere, în urma prelucrării datelor disponibile.

Sistemul informatic este compus din:

Intrările

Prelucrările

Ieșirile

extern date informații cunostințe

intern

Structura unui sistem informatic

1.2. Clasificarea sistemelor informatice

Sistemele informatice se pot clasifica astfel: 1

În funcție de domeniul de utilizare:

conducerea proceselor tehnologice

1 I. Lungu, Gh. Sabău, M. Velicanu, M. Muntean, S. Ionescu, E. Posdarie, D. Sandu, Sisteme informatice. Analiză, proiectare și implementare, Editura Economică, București 2003

conducerea activităților economico-sociale

cercetare științifică și proiectare tehnologică

activități speciale.

În funcție de nivelul ierarhic ocupat de sistemul economic în structura organizatorică a societății, conform căruia există sisteme informatice:

pentru conducerea activității la nivelul unităților economice

pentru conducerea activității la nivelul organizațiilor economico-sociale cu structură de grup

sisteme informatice teritoriale

pentru conducerea ramurilor, subramurilor și activităților la nivelul economiei naționale

sisteme informatice funcționale generale .

În funcție de elementul supus analizei :

sisteme informatice orientate spre funcții;

sisteme informatice orientate spre proces;

sisteme informatice orientate spre date;

sisteme informatice orientate spre obiecte;

sisteme informatice orientate spre cunoștințe.

După modul de organizare a datelor :

sisteme bazate pe fișiere;

sisteme bazate pe tehnica bazelor de date: ierarhice, rețea, relaționale, orientate-obiect;

sisteme mixte.

După metoda folosită în analiza și proiectarea sistemelor:

sisteme dezvoltate după metoda sistemelor;

sisteme dezvoltate după metoda clasică a ciclului de viață;

sisteme dezvoltate după metoda structurată;

sisteme dezvoltate după metoda orientată-obiect;

sisteme dezvoltate după metoda rapidă(RAD);

sisteme dezvoltate după metoda echipelor mixte(JAD);

sisteme dezvoltate după metoda prototipurilor.

După gradul de centralizare :

sisteme centralizate;

sisteme descentralizate;

După gradul de dispersie a resurselor sistemului informatic:

sisteme informatice locale (bazate pe rețea locală, stații de lucru):

sisteme informatice distribuite (date distribuite).

După gradul de automatizare a activităților de analiză și proiectare a sistemelor informatice :

sisteme informatice dezvoltate pe baza analizei și proiectării clasice;

sisteme informatice analizate cu instrumente automate și proiectate clasic;

sisteme informatice bazate pe instrumente diverse de automatizare a analizei și proiectării;

sisteme informatice dezvoltate cu instrumente de tip CASE.

1.3. Arhitectura sistemelor informatice

Un sistem informatic este compus din :

baza informațională; – datele supuse prelucrării

– fluxurile informaționale

– sistemele și nomenclatoarele de coduri

baza tehnică – mijloacele de stocare, prelucrare, culegere si transmitere a datelor, computerele fiind elementul de bază.

sistemul de programe – Sistemul informatic, pentru a opera în conformitate cu obiectivele stabilite, are nevoie de o serie de programe. Totalitatea acestora formează sistemul de programe, si sunt cuprinse aici atât programele de bază, cât si programele aplicative. ;

baza științifică și metodologică – este alcătuită din tehnici de realizare a sistemelor informatice, algoritmi, formule si modele.

factorul uman (resursele umane) – personalul specializat ( programatori, analiști, ingineri de sistem) alături de beneficiariii sistemului;

cadrul organizatoric – este specializat în funcție de unitatea unde va fi utilizat sistemul informatic

1.4. Ciclul de viață al unui sistem informatic

Ciclul de viață al sistemelor informatice (SI) pleacă de la decizia realizării unui nou SI. Aceasta vine de obicei din dorința de a raspunde mai bine cerințelor utilizatorilor. Și se încheie în momentul în care SI-ul existent este înlocuit de unul mai performant. Fiecare etapă a ciclului de viață a SI-urilor are faze și activități specifice bine definite.

Sistemele informatice se modifică constant, fie apărând versiuni noi, îmbunătățite ale sistemului existent, fie dezvoltându-se un nou sistem în totalitate. Evoluția din domeniul tehnologiei informației, dar si schimbarea metodelor de abordare a sistemlor și-a pus amprenta asupra ciclului de viață al SI-urilor, modificându-i etapele de realizare sau optica de parcurgere a acestora.

În funcție de complexitatea abordării, în literatura de specialitate se pot detalia de la trei etape de viață ale SI (analiză, proiectare, implementare) si mergând până la peste douazeci.

Există mai multe modele ale ciclului de viață, multe dintre ele cunoscând o evoluție în timp. Spre exemplu, modelul cascadă prevede parcurgerea mai multor etape ale ciclului de viață care se derulează secvențial fiind însă permisă la nevoie revenirea la etapa parcursă anterior în vederea îndepărtării neajunsurilor identificate în etapele superioare ale ciclului de viață.

Etape ale ciclului de viață a unui sistem informatic în modelul cascadă :

1. Analiza și definirea cerințelor – sunt definite scopurile, serviciile și restricțiile pe care trebuie să le îndeplinească sistemul informatic, prezentate într-o manieră încât să poată fi înțelese atât de către utilizatorii sistemului cât și de personalul de proiectare.

2. Proiectarea sistemului și software-ului – satabilirea cerințelor pentru hardware și software și elaborarea arhitecturii generale a sistemului. Funcțiile sistemului informațional vor fi reprezentate astfel încât să poată fi tranformate în unul sau mai multe programe executabile.

3. Implementarea și testarea unităților de program – proiectarea software-ului din etapa anterioară este transpusă într-o mulțime de programe sau module programși verificarea faptului că fiecare program sau modul satisface specificația sa.

4. Integrarea și testarea sistemului – integrarea și testarea programelor și modulelor program ca un sistem complet pentru a ne asigura că cerințele informaționale sunt satisfăcute. După testare sistemul este livrat beneficiarului.

5. Exploatarea și întreținerea sistemului – este faza în care sistemul informatic este efectiv utilizat de către beneficiar și în care sunt descoperite și rezolvate eventuale erori de proiectare și programare și omisiuni în cerințele informaționale inițiale.

1.5. Tema lucrarii

Lucrarea consta în realizarea unei aplicați care să ofere un sistem informatic pentru departamentul de vânzări al unei tipografii. Sistemul informatic are ca scop evidența clienților și a comenzilor acestora, precum și emiterea de facturi. Pentru realizarea aplicației am folosit cunoștiințele acumulate pe parcursul anilor de studiu, în special cele referitoare la baze de date și programare orientată pe obiecte, utilizând un server pentru baza de date, creată în SQL Server cu ajutorul limbajului universal SQL, iar aplicația propriu-zisă a fost realizată prin limbajul de programare C#.

Capitolul 2. Analiza și cerințele unui sistem informatic

Logistica de vânzări este procesul prin care o firmă organizează, planifică, și controlează clienții și comenzile acestora. Astfel se asigură preluarea comenzilor, se verifică scadența acestora, livrarea la timp, emiterea facturilor aferente și urmărirea plaților.

Specificarea cerințelor

O societate comercială dorește informatizarea activității sale de preluare comenzi și vânzări. Sistemul informatic va permite gestionarea acestui departament: evidența clienților, preluarea comenzilor, verificare disponibilitate stocuri si abilitatea de a realiza comenzile, emiterea și printarea de facturi, urmărirea termenelor de livrare și de plata, etc.

2.1. Diagrama Cazurilor de Utilizare (Use Case Diagram)

diagramă a cazurilor de utilizare (use case diagram) prezintă o colecție de cazuri de utilizare și actori care :

oferă o descriere generală a modului în care va fi utilizat sistemul;

furnizează o privire de ansamblu a funcționalităților ce se doresc a fi oferite de sistem;

arată cum interacționează sistemul cu unul sau mai mulți actori;

asigură faptul că sistemul va produce ceea ce s-a dorit

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. Cum actorii reprezintă utilizatorii sistemului, ei ajută la delimitarea sistemului și oferă claritate în ceea ce se va întâmpla în respectivul sistem.2

Un actor poate fi reprezentat de mai multe persoane, dar si o persoana poate interpreta rolul mai multor actori. Actorii se reprezintă sub forma unor mici personaje având propriul său nume ca în figura 2.1.:

Fig. 2.1. Reprezentarea unui Manager în notația UML

Următoarele întrebări marchează un actor:

Cine este interesat de informațiile aflate în sistem?

Cine modifică date?

Cine interacționează cu sistemul?

Între actori poate exista relația de generalizare. Asta implică moștenirea unui actor de către alt actor și deci aceleași cazuri de utilizare ca și părintele său.

Când un actor are nevoie de un rezultat dintr-un program, execută o serie de actiuni. Aceasta se numeste un caz de utilizare (use case).

Reprezentarea cazurilor de utilizare în UML

Cazurile de utilizarea în modelarea UML se reprezintă grafic printr-o elipsă(Fig.2.2.), fiecare având un nume prin care se deosebește de celelalte cazuri :

, – un șir arbitrar de caractere

2 Emilian Guțuleac, Ingineria Programării, Universitatea Tehnică a Moldovei, Chisinău 2011

fraze verbale prin care prin care se denumește un comportament existent în vocabularul sistemului care urmează a fi modelat

Fig.2.2. Reprezentarea grafică a unui use case în UML

Comportamentul use case-urilor este specificat prin descrierea unui flux de evenimente într-un text destul de clar pentru a putea fi înțeles de un utilizator, acest flux putând să includă :

modul în care începe si se termină use case-ul atunci când acesta interacționează cu

actori

obiectele care sunt interschimbate

fluxurile alternative ale acestui comportament

Identificarea cazurilor de utilizare

Un mod de a identifica cazurile de utilizare, este prin a se începe identificarea actorilor, pentru fiecare actor fiind puse următoarele întrebări :

Care sunt funcționalitățile din sistem pe care actorul trebuie să le acceseze?

Este nevoie ca actorul să citească și/sau să actualizeze anumite date din sistem?

Există în sistem evenimente pe care actorul trebuie să le cunoască?

Folosirea de noi funcționalități este un mod de ușurare a muncii actorului?

Totodată, identificarea cazurilor de utilizare poate fi realizată și prin alte întrebări, fără a fi necesară folosirea actorilor :

Care sunt ieșirile și intrările necesare în sistem și direcțiile acestora ?

Ce probleme întâlnește sistemul la implementarea sa ?

Relații într-o diagramă a cazurilor de utilizare

Relațiile dintr-o diagramă a cazurilor de utilizare exprimă interacțiuni între actori, între use case-uri sau între actori și use case-uri și pot fi relații de :

Asociere

Dependență

Generalizare

Relația de asociere :

Reprezintă comunicarea dintre un actor și un caz de utilizare sau între doua cazuri de utilizare. Se reprezintă grafic printr-o linie și este evidențiată în figurile de mai jos ( Fig.2.3 și 2.4 ).

Fig.2.3 Exemplu de asociere între actor și use case

Fig.2.4 Exemplu de asociere între use case-uri

Relația de dependență :

Apare doar între doua cazuri de utilizare și modelează una dintre situațiile de mai jos:

Include – un caz de utilizare folosește funcționalitatea oferită de un alt caz de utilizare

Extend – există variante ale aceluiași caz de utilizare

Dependența de tip include, marchează o similaritate în comportamentul cazurilor de utilizare. Cazul de utilizare inclus este de sine stătător, însă este necesar pentru funcționarea celui care îl include.

Dependența de tip extend, marchează locul în care un caz de utilizare extinde un caz de utilizare de bază, înglobându-și comportamentul în acesta, dar ambele fiind de sine stătătoare.

Relația de generalizare

Este o relație similară relației de moștenire dintre clase și se stabilește între elementele de același tip :

actori

use case-uri

Această relație marchează faptul că elementul de bază este moștenit de elementul derivat, iar cazul de utilizare derivat controlează ce anume se execută și se modifică din cazul de utilizare de bază.

În figura 2.5 este prezentată detalierea diagramei cazurilor de utilizare a sistemului informatic care urmeaza a fi realizat :

Fig.2.5 Diagrama cazurilor de utilizare

În continuare, vor fi prezentate cateva dintre compomentele unui astfel, relațional la figura de mai sus, astfel :

Manager – actorul sistemului, care efectuează operațiile prezentate în use-caseuri.

Adaugă client nou – cazul de utilizare pentru adăugarea noilor clienti.

Modifică date client – cazul de utilizare prin care se efectuează operații de editare a datelor unui client.

2.2. Diagrama fluxului de date a aplicației ( Data Flow Diagram)

Diagramele de flux de date sunt orientate către operații de flux. Obiectele sunt afișate în relații cu procedurile. Nu este afișată nici o logică de decizie, diagrama este adeseori utilizată pentru a modela fluxul de date. Cum aceste diagrame sunt destul de complexe, este utilizată convenția H-graph, în care un anumit nod va fi expandat în alte subnoduri.

Diagrama de flux de date ale sistemului logic evidențiază funcțiile de prelucrare a datelor executate de către sistemul informațional în cadrul circuitul datelor, și detaliază structura lor și cerințele funcționale ale noului sistem. Aceasta se desfăsoară independent de tehnologie.

Diagramele de flux se mai numesc si modele ale proceselor de prelucrare, deoarece au ca scop modelarea proceselor și urmaresc modul de transfer al datelor între procesele de prelucrare a lor.

Tehnica SSADM (Structured Systems Analysis and Design Methodology) pentru construirea DFD 3

Când analizăm sistemele folosim frecvent reprezentările grafice, de exemplu diagramele. În continuare vom folosi tehnica reprezentării grafice a fluxului informațional. Proiectarea fluxului informațional reprezintă circulația informației în sistem, transformările suferite de acesta, stocarea informației precum și scurgerile de informație în afara sistemului.

Scopul diagramelor de date DFD pentru o anumită componentă organizatorică sau funcțională la care se referă (secție, birou, compartiment, întreaga unitate, o anumită activitate – vânzări, cumpărări, încasări, plăți, ș.a) este de a scoate în relief, într-o manieră cât mai sugestivă, următoarele aspecte :

sursa datelor de prelucrare;

operațiunile de prelucrare prin care trec datele;

destinația datelor prelucrate;

legătura existentă între prelucrări și activitatea de stocare a datelor.

Întocmirea diagramelor de flux de date (DFD)

DFD este o reprezentare grafică a transformării datelor de intrare în date de ieșire
folosind un set de simboluri de reprezentare și un set de reguli de completare și validare.

3 http://www.seap.usv.ro/~sorinv/PSI.pdf

Simboluri folosite în diagramele realizate cu SSADM:

Convenții folosite în diagramele de reprezentare a DFD:

numerotarea consecutivă ( fără însă a reprezenta ordinea în care se execută) a proceselor si stocurilor de date

entitățile externe și stocurile de date se pot duplica, pentru a nu încărca diagrama și a o păstra ușor de citit si interpretat.. O linie oblică va reprezenta o entitate externă, iar o linie suplimentară verticală în partea stângă a cutiei – un stoc duplicat

se recomanda organizarea diagramei astfel: în exterior se plasează entitățile externe, iar în partea centrală stocurile de date. Aceasta tot pentru a nu încărca diagrama și a o păstra ușor de citit si interpretat.

fluxurile de date de la – către stocurile de date sunt unidirecționale (fie de adăugare, fie de consultare) si nu sunt etichetate.

Fig. 2.6 Data Flow Diagram

Capitolul 3. Proiectarea sistemului informatic

Proiectarea sistemului informatic se desfășoară pe două direcții, acestea fiind:

Proiectarea bazei de date relationale: se urmareste descrierea atributelor entităților, dar și explicitarea legăturilor dintre acestea. Toate acestea putând fi posibile urmarind și imbunatățind diagrama Entitate-Legatura realizată în faza de analiză a sistemlui informatic.

Proiectarea aplicatiei 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 comport 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 stari ale aplicației.

3.1. Proiectearea bazei de date

Principiul dupa care se realizeaza proiectarea bazei de date este acela al abstractizării datelor. Acesta reprezintă unul din principiile fundamentale aplicate în proiectarea sistemelor informatice. Acesta usurează analizarea unui sistem complex, permițând doar anumite aspecte să fie tratate la un moment dat, ignorând altele, la care se va revenii ulterior, odata ce primele aspecte au fost tratate.

Principiul abstractizării în modelarea datelor presupune existența a trei niveluri de abstractizare: conceptual, logic și fizic.

3.1.1. Etapele proiectarii bazei de date

Proiectarea bazelor de date se poate realiza în trei etape:

analiza cerințelor sistemului și modelarea conceptuală a datelor;

proiectarea logică a bazei de date;

proiectarea fizică a bazei de date.

Modelarea conceptuală a datelor presupune creearea unui model al datelor care sa urmărească exact realitatea din domeniul analizat. Acesta nu va ține cont de vreun mod specific de organizare a datelor si de criterii de performantă sau calitate ale organizării, stocării sau accesării datelor. Rezultatul va fii diagrama entitate-relație, cu toate entitățiile și legăturile dintre acestea ( modul de implementare al acestora nu este relevant în această fază). Vor fi evidențiate doar atributele entitățiilor, și identificarea și descrierea legăturilor).

Proiectarea logică urmează modelării conceptuale a datelor si urmărește transformarea acesteia conform criteriilor de calitate ale organizării, aspecte care nu au fost luate în considerare în etapa precedentă. Va rezulta organizarea datelor în tabele si coloane, conform regulilor modelului relațional. Însă și în această etapă se vor ignora cerințele nefuncționale și de performanță rezultând un model relaționar pur. Aceste cerințe vor fi luate în considerare în etapa proiectării fizice a bazei de date.

Nivelurile de abstractizare a datelor este in figura de mai jos.

3.1.2. Demersul proiectării bazelor de date

Modelul entitate-relație

Elementele principale sunt definite de conceptele: 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.

Entitățile sunt reprezentate printr-un dreptunghi, în cadrul căruia se află numele prezentat printr-un substantiv, iar în cadrul sistemului fiecare entitate are un nume unic.

O relație reprezintă o legătură între două sau mai multe entități, intr-o schemă conceptuală, fiecare relație avand un nume unic, reprezentat prin verbe, iar între două entități pot exista mai multe relații.

Un atribut este o proprietate care descrie o caracteristică a unei entități sau a unei relații. Atributele asociază fiecărei apariții a unei entități (sau relații) o valoare aparținând unei mulțimi denumite domeniul atributului. Domeniul conține valori admisibile pentru atribut.

Atributul simplu este un atribut cu o singură componentă, care are o existență independentă.

Atributul compus este mulțime de atribute ale aceleași entități sau relații ale căror înțelesuri sau utilizări sunt strâns conectate.

Cardinalitatea unei relații descrie numărul minim sau maxim de apariții ale relației la care poate participa o apariție a entității. Este specificată separat pentru fiecare entitate participantă la relație. Este posibil să se atribuie orice valoare întreagă mai mare ca 0 cardinalității unei relații, după cum urmează:

cardinalitatea minimă 0 – participare opțională la relație

cardinalitatea minimă 1 – participare obligatorie la relație

cardinalitatea maximă 1 – fiecare apariție a entității este asociată cel mult unei singure apariții a relației

cardinalitatea maximă N – fiecare apariție a entității este asociată unui număr arbitrar de apariții ale relației

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

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

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

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

Entitațile de date, proprietățile acestora și legăturile dintre ele vor face obiectul modelării conceptuale a datelor. Va rezulta diagrama Entitate-Relație (ERD). Pentru a ajunge la forma finală a bazelor de date, aceasta diagramă va fi transformată în schema logică și aceasta va fi supusă normalizării.

Diagrama entitate-relatie (ERD attribute)

Se realizeaza prin transpunerea modelului entitate-relatie în urma a trei pasi :

Transformarea entităților :

entitățile se transformă în tabele

trebuie asigurată unicitatea numelor tabelelor în baza de date

Datorită faptului că entitățile sunt de diferite tipuri, putem spune că există mai multe tipuri de transformări, după cum urmează :

entitățile puternice devin tabele independente, în cadrul cărora cheia primară nu poate să conțină chei străine

entitățile slabe se transformă în tabele dependente, aflate în relații cu tabelele corespunzătoare mulțimii de entități de care acestea depind. Pentru realizarea acestor relații se adaugă o cheie străină care referă cheia primară a entității de care depinde entitatea din tabelul dependent.

Tranformarea relațiilor :

Relația binară 1:N dintre două entități se realizează prin intermediul unei chei străine în tabelul ce conține partea “mulți” a relației, care referă cheia primară din primul tabel.

Relația binară M:N dintre două mulțimi de entități se realizeaza cu ajutorul unui nou tabel, numit tabel de asociere, care conține două chei străine, pentru fiecare din cele două tabele asociate. Cheia primară a acestui tabel poate fi o cheie primară artificială, sau poate fi compusă din cele două chei străine.

Relația binară 1:1 se realizează în două moduri, fie prin introducerea unei chei străine, devenind un caz particular a relației 1:N, poziția sa depinzând de cardinalitatea minimă a relației, fie printr-un tabel de asociere.

Relația multiplă M:N:P se realizează prin introducerea unui tabel asociativ, în cadrul căruia se introduc chei străine care referă tabelele care se asociază, fiecare cheie străină referind cheia primară din tabelul asociat. Cheia primară a unui astfel de tabel poate fi o cheie artificială, sau poate fi compusă din din toate celelalte chei străine, împreună cu alte atribute.

Normalizarea tabelelor

Tabelele create în pașii 1 și 2 pot conține redundanțe nedorite și vor constitui surse de înregistrare a anomaliilor în timpul actualizării. Normalizarea va conduce la o bună structurare a tabelelor.

După cum se poate observa, în transpunerea componentelor modelului E/R, întâlnim terminologia de cheie primară, cheie străină, cheie artificială, cheie compusă. Astfel, putem enunța că o cheie este un câmp special dintr-un tabel care îndeplinește roluri foarte bine determinate, iar tipul cheii stabilește rolul acesteia în interiorul tabelului. Cele mai importante tipuri de chei din cadrul unui tabel sunt cheia primară și cheia străină.

Cheia primară este un câmp sau un grup de câmpuri care defineste în mod unic fiecare înregistrare din cadrul unui tabel. Fiecare înregistrare din întreaga bază de date poate fi gasită cu ajutorul unei singure valori a cheii primare. Cheia primară ușurează stabilirea legăturilor cu alte tabele din baza de date și garantează integritatea la nivel de tabel.

Cheia străină a unui tabel este acea cheie care este cheie primară în alt tabel. Se foloseste în principal pentru a lega tabele între ele, de aceea unicitatea ei nu e obligatorie. Cheile străine stau la baza modelul relațional, toate relații fiind realizate cu ajutorul lor.

După ce în procesul de proiectare a bazei de date am obținut schema conceptuală și cea logică se poate trece la momentul proiectării fizice. Schema conceptuală este folosită în documentare, deoarece reprezintă o prezentare de nivel înalt a bazei de date. Schema logică este utilă pentru realizarea interogărilor și modificărilor bazei de date, deoarece ignoră aspectele de implementare si se orientează spre descrierea conținutului bazei de date,

Schema logică, obținută în urma transpunerii schemei E/R pe baza tranformărilor de mai sus este prezentată în figura 3.1:

Fig.3.1 Diagrama logică a bazei de date ( ERD atribute )

Observând diagrama din imaginea de mai sus, putem constata că aceasta conținte toate elementele descrise anterior. Astfel se poate observa transformarea entității Salariați în tabelul CUSTOMERS, cu transformarea atributelor în coloanele tabelului ( Id, Name, Phone, Email, Fax, FirstName, LastName, Adress, CreatedOn, CreatedBy, ModifiedOn, ModifiedBy). Totodată se poate observa și cum relația M-N între entitățile ORDER și PRODUCT s-a transformat într-un tabel asociativ ORDERITEM care conține ca și chei străine, câmpurile Order_Id și Product_Id, care sunt chei primare în tabelele ORDER și PRODUCT.

Tabelele asociate diagramei sunt :

Order (Id, OrderNumber, OrderAmount, DeliveryAdress, PaymentMethod, AddAditionalNotes, CreatedOn, CreatedBy, ModifiedOn, ModifiedBy, CustomerId, OrderStatus, DueDate)

Product (Id, Name, Price, Details, PriceQuantity, CreatedOn, CreatedBy, ModifiedOn, ModifiedBy, ProductCategoryId)

ProductCategory (Id, Name, Description, CreatedOn, CreatedBy, ModifiedOn, ModifiedBy, MainCategoryId)

Invoice (Id, OrderId, Amount, CreatedOn, CreatedBy, ModifiedOn, ModifiedBy, ProductCategoryId, InvoiceNumber, InvoiceStatus)

Avantajele utilizării modelului Entitate-Relație ER:

pe parcursul fazelor de analiză și proiectare logică facilitează comunicarea între proiectanții sistemului si utilizatorii acestuia.

datorită posibilității prezentării sub forma de grafice si scheme, permite urmărirea și întelegerea ușoară a unui volum mare de informatii.

abstractizarea facilitează analiza și proiectarea bazei de date, reducînd considerabil numărul obiectelor care trebuie considerate. Prin folosirea notiunii de entitate pentru a reprezenta datele de bază (atribute), se reduce numărul de obiecte si relații între obiecte de analizat ( numărul entităților de date și a relațiilor dintre acestea este mai mic decât numărul datelor elementare din sistem și numărul relațiilor de dependență existente între atribute). Deasemenea, fiind luate în considerare doar dependențele la nivelul entităților, numărul dependențelor ce trebuie analizate este mult redus.

transformarea simplă și rapidă a cerințelor informaționale ale sistemului, structurate în ERD, în baza de date, datorată existența unui set complet de reguli de transformare.

posibilitatea de a generara automat baza de date în funcție de SGBD-ul dorit.

Astfel, întâlnim două strategii de proiectare a bazei de date:

strategia bottom-up, pentru a se obține tabelele bazei de date se merge pe metoda tradițională – se construiesc relațiile care apoi sunt normalizate;

strategia top-down, pentru a se obține tabelele bazei de date se aplică setul de reguli de transformare ERDului după ce a fost obținut. Deasemenea, vor fi supuse normalizării.

3.2. Proiectarea aplicației

Diagramele care fac parte din această categorie și cu ajutorul cărora o să proiectăm aplicația sunt :

diagrama de activități

diagrama de stări

diagrama de segvență

diagrama de colaborare

3.2.1. Diagrama de activități

În principiu, o diagrama de activitate reprezintă o metoda simpla si intuitiva de a ilustra ceea ce se intampla în cadrul unui caz de utilizare, sau al unui proces ce se desfasoara in interiorul sistemului informatic. Prin astfel de diagrame se doreste prezentarea unor lucruri ca de exemplu: ce activități pot sa fie facute in paralel, care sunt pașii care se executa, sau daca există drumuri diferite pentru a execuția unor acțiunii .

Acest tip de diagrame au fost concepute în primă fază pentru pentru modelarea sistemelor la nivelu ințelegerii bussinesului în care acestea trebueisc 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 pană î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, scopul principal pe care se axeaza diagrama este de a descrie secventele acțiunilor de executat și a condițiilor care declanșeaza sau care se impun asupra acțiunilor descrise. Deasemenea diagrama de activități, 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 find intreaga activitate modelată prin diagramă ( formată printr-o succesiune de acțiuni ). In modelul orientat pe obiecte activitățile sunt de obicei considerate ca fiind metode legate diferitelor operațiuni care sunt invocate in cadrul claselor. Datorită faptului că definesc întreaga activitate din cadrul diagramei de activități, nu exista 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 in continuare in cadrul acestui tip de diagramă. Legatura importantă intre Activitate și Acțiune este acea conform căreia o ativitate este o element comportamental care este compus din mai multe elemente individuale, care sunt reprezentate de către acțiuni. Din punctul de vedere al activității care o conține, o acțiune este foarte simplă, dar ea poate fi foarte complexă in efect si construcție. În comparația cu o activitate, care poate fi refolosită în mai multe locuri, acțiunea este o instanță care este folosită doar in cadrul activității in care este inglobată.

Perioada de viață a unei acțiuni începe de indată ce toate condițiile ei de funcționare sunt indeplinite și in acelasi timp, toate datele de care are nevoie la intrare ii sunt livrate, în același timp, finalul unei acțiuni declanseaza automat inceperea execuției altei acțiuni succesoare acesteia, a carei date de intrare corespund cu datele de iesire a acțiunii care se termina.

Vizual , î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, indică acțiunea pe care o reprezintă figura. O astfel de acțiune este reprezentată în figura 3.2 .

Figura 3.2: Reprezentare grafica 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 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.

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

Figura 3.3 : Reprezentare grafica a Punctului inițial

Punct final

Orice activitate descrisă într-o diagramă de activitate trebuie să aibă un punct de final, punct în care activitatea să se oprească. Spre deosebire de punctul de start, o activitate poate avea mai multe puncte de final. Primul punct final întalnit în parcursul vieții unei acțiuni, declanseaza 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.

Figura 3.4: 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ții între două acțiuni poate fi observată in figura 3.5.

Figura 3.5: Reprezentare grafică Tranziție între doua acțiuni

Punct de decizie

În cadrul unei digrame de activitate pot exista locuri în care să trebuiască luate anumite decizii în funcție de rezultatul de la iesirea unei acțiuni. In modelarea unor astfel de cazuri, este nevoie de modelarea a două sau mai multe secvențe de acțiuni. Modelul de realizare a unor astfel de decizii este printr-o tranziție care vine dinspre o acțiune către punctul de decizie, iar din acesta pleaca două sau mai multe tranziții către alte acțiuni, în funcție de rezultatul asupra caruia se efectuează decizia.

Reprezentarea grafică a unui punct de decizie este sub forma unui romb în care intră o tranziție și ies alte doua sau mai multe tranziții. Valorile în funcție de care se face decizia sunt trecute pe tranzițiile care ies, și sunt încadrate între paranteze pătrate.

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 in modelarea a mai multe fire de execuție care fac patre din aceeasi activitate. Reprezentarea grafica poate fi observată în figura 3.6.

Figura 3.6: Reprezentare grafică Nod de sincronizare

Culoar

Culoarele sunt obiecte care permit separarea acțiunilor din cadrul unei activități în funcție de cine este executantul lor. Sunt foarte folositoare pentru structurarea diagramei și în a ajuta la o mai bună înțelegere a diagramei. Grafic ele pot lua ami multe forme, ele avand doar roul de a grupa acțiunile.

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 validare a comenzilor. Validarea propriu zisă se face de către Manager, în urma verificării disponibilității produselor. Astfel activitatea presupune executarea acțiunilor de recepționare a comenzii, trimitere spre procesare, verificare disponibilitate produse, realizare a comenzii, finalizarea si expediția ei. Diagrama descrisă mai jos este reprezentată în figura 3.7.

3.2.2. Diagrama tranzitiilor de stare ( State Diagram )

Diagrama de stare a tranzițiilor este folosită pentru a reprezenta stările prin care trec anumite obiecte, evenimente care determina 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 caror componente sunt afectate de schimbari de stare ale obiectelor care le compun.

Scopul acestor diagrame este de a descrie raspunsul ș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 obiectele instanțiate ale unei clase sau unor cazuri de utilizare, din cadrul diagramei cazurilor de utilizare.

Componentele principale ale unei diagrame de tranziție sunt : stările, tranzițiile, punctele de decizie, punctele de intratre și de ieșire .

Starea

O stare este definită de către multimea 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 rândul 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 afișat un nume sugestiv pentru fiecare stare. Reprezentarea grafică a unei stări poate fi observată în figura 3.8.

Figura 3.8: 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.

Există doua tipuri de realizare a unei tranziții, prin structuri secvențiale și structuri alternative.

Structura secvențială reprezintă conexiunea directă între două stări.

Structura alternativă este structura care permite alegerea stării următoare în funcție de anumite condiții.

Combinația acestor două structuri permite obținerea structurilor repetitive.

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țtiunile care au loc pe parcursul tranzițiilor. Reprezentarea grafica a unei tranziții poate fi observată in figura 3.9 .

Figura 3.9: Reprezentare grafică a unei Tranziții

Punctele de intrare și de ieșire

Punctul de intrare si de ieșire al diagramei reprezinta punctele din care pleacă și se termină tranziția stărilor princ are trece obiectul.

Puncte de decizie

Sunt puncte care permit împărțirea tranziției in 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.10 .

Figura 3.10: Reprezentare grafică Punct de decizie

Pentru sistemul informatic proiectat pâna în acest moment, sunt necesare alcătuirea a doua 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 starea în care datele clienților au fost adaugate și se continua 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 numărul de produse. După această stare urmează un punct de decizie, punct din care se poate reveni al starea în care se vizualizează catalogul de produse din nou, în evderea adăugării unui alt produs, sau se poate continua cu starea de Comandă lansată, stare care este și starea finală a sistemului. În figura 3.11 se poate observa această diagramă de stare a tranzițiilor pentru sistemul informatic, în momentul introducerii unei noi comenzi în sistem.

Figura 3.11: Diagrama de stare a tranzițiilor sistemului informatic la adăugarea unei comenzi

Pentru a detalia stările prin care trece un obiect al clasei cerere, 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 diferite stadii din proces. În momentul în care o comandă este lansată, aceasta este recepționată, înregistrată, aprobată, efectuată și în final livrată. Diagrama stărilor de tranziție este prezentată mai sus în figura 3.11.

3.2.3 Diagrama de secvență(Sequence Diagram)

Diagrama de secvență pune accentul pe componenta temporală a interacțiunilor dintre obiecte și, spre deosebire de alte diagrame, nu este detaliat contextul obiectelor.

O diagramă de secvență reprezintă grafic, în ordine cronologică, circulația mesajelor transmise între obiecte.

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

Obiectele care interactionează între ele sunt văzute ca linii verticale distribuite pe orizontală. Ele se reprezintă grafic prin dreptunghiuri în cadrul cărora sunt scrise numele.

Liniile de viață sunt componente specifice diagramei de secvență, ele reprezentând axa timpului pentru diagramă, astfel cronologia expedierii mesajelor fiind redată de apariția lor pe axe. Liniile de viață se reprezintă printr-o linie verticală punctată, fiecare obiect având o o astfel de linie.

Mesajele expediate între obiecte se reprezintă grafic prin săgeți între liniile de viață ale obiectelor. Se va ține cont de ordinea cronologică.

În figura de mai jos(fig.3.12) este prezentată diagrama de secvențe pentru cazul de utilizare comandă clienți:

Fig.3.12 Diagrama de secvență pentru comanda clienților

După cum se poate observa, diagrama conține toate elementele de bază enumerate mai sus, reprezentate grafic după cum a fost specificat.

3.2.4 Diagrama de comunicare (Communication Diagram)

Diagramele de comunicare sunt diagrame de interacțiune, ce evidențiază conexiunile dintre obiectele care interactionează prin expedierea de mesaje. În timp ce la diagrama de secvență se pune accent pe cronologie, la diagrama de comunicare, spatiul este elementul care se ia în considerare. Din acest motiv cu diagramele de comunicare nu se pot reprezenta mesajele asincrone și cele concurente și, tot din același motiv, în diagramele de comunicare este obligatorie numerotarea mesajelor pentru a se indica secvența lor.

Deoarece diagramele de comunicare prezintă instanțe și nu clase, ele surprind și situații particulare sau de excepție. De exemplu (fig. 3.13), se poate prezenta cazul în care o comandă de vânzare nu poate fi onorată imediat, datorită insuficienței stocurilor, situație în care este necesară crearea unei comenzi de aprovizionare. Acea comandă de aprovizionare, după ce este creată, duce la realizarea unei aprovizionări care va modifica stocul și va face posibilă onorarea comenzii de vânzare.

Capitolul 4. Implementarea sistemului informatic

Implementarea este procesul traducerii algoritmului obținut în urma fazei de proiectare într-un limbaj de programare. La prima vedere implementarea nu ridică probleme deosebite, ea însemnând doar traducerea algoritmului din faza de proiectare în limbajul de programare ales. Evident, cel care face această traducere trebuie să cunoască foarte bine limbajul de programare dar și limbajul de descriere a algoritmului. Implementarea si proiectarea sistemului informatic se realizeaza in doua etape:

implementarea bazei de date

implementarea aplicației

4.1. Implemantarea bazei de date

Implementarea este etapa care include realizarea fizica a bazei de date prin utilizarea limbajului de definire a datelor al sistemului de gestiune al bazelor de date (SGBD), și implementarea programelor de aplicație realizat în limbajul ales. Proiectarea fizică a bazelor de date și a fișierelor își propune să asigure trecerea de la descrierea logică a datelor la una tehnică, de stocare a datelor.

4.1.1. Microsoft SQL Server

Microsoft SQL Server este un server de baze de date produs de firma Microsoft, mult mai complex decât celelalte produse oferite de această firmă și care poate lucra cu aplicații de tipul client-server, presupunând acces continuu la o anumită bază de date.

SQL Server dispune de un sistem de securitate propriu, pe bază de identificatori și utilizatori ai bazelor de date, iar informațiile sunt stocate în cadrul lui în baze de date, fișiere și grupuri de fișiere.

4.1.2. Baze de date in SQL Server

SQL Server oferă foarte multe facilități pentru buna funcționare a bazelor de date care sunt administrate și realizate cu ajutorul lui. În acest sens au fost dezvoltate o serie de utilitare care sunt menite sa 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.

altă caracteristică importantă este dată de către felul in care SQL Server îsi organizază fizic bazele de date care sunt administrate cu ajutorul acestei aplicații.

Bazele de date sistem

Î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).

Baza de date msdb – este utilizată pentru a stoca date referitoare la sarcinile pe care ”Agentul” folosit de către SQL Server 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 create ș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 fisier primar de date – conține date, dar și referințe către restul fisierelor care alcătuiesc baza de date

Un fisier jurnal – aici sunt stocate toate modificările asupra bazei de date, acest lucru poate fi utilizat pentru recuperarea datelor pierdute în cazul unor erori.

Pe langă aceste două fisiere care pot fi regăsite sigur în cadrul salvării unei baze de date, se mai pot găsi și alte fișiere secundare de date, care nu sunt stocate în cadrul fișierului primar. Aceste fișiere se regăesc mai ales în cadrul bazelor de date destul de mari încât să fie necesară folositea acestui tip de fisiere.

4.1.3. Limbajul SQL

Structured Query Language (SQL) este un limbaj universal, non-procedural, usor de folosit pentru începători, dar cu funcții puternice pentru utilizatori experimentati, care poate fi utilizat pentru a defini, interoga, reactualiza și gestiona baze de date relaționale. Acesta este folosit, de obicei, alaturi de alte limbaje de programare, dar poate fi utilizat autonom.

Operațiile SQL asupra unei baze de date

să schimbe structura unei baze de date;

să modifice valorile de configurare pentru securitatea sistemului;

să solicite informații dintr-o bază de date;

să restricționeze accesul utilizatorilor asupra anumitor bazelor de date sau tabelelor;

să modifice conținutul bazei de date.

În SQL utilizează trei tipuri de limbaje pentru operarea asupra datelor, fiecare limbaj având comenzile sale specifice.

limbajul de definire a datelor (LDD) cu comenzi pentru definirea datelor, care permit descrierea (definirea) obiectelor ce modelează sistemul studiat.

limbajul de manipulare a datelor (LMD) cu comenzi pentru manipularea datelor, care permit consultarea, reactualizarea, suprimarea sau inserarea datelor. Aceste comenzi definesc să adauge drepturi utilizatorilor asupra bazelor de date sau tabelelor;

limbajul de control al datelor (LCD) cu comenzi pentru controlul datelor, care permit asigurarea confidențialității și integrității datelor, salvarea informației, realizarea fizică a modificărilor în baza de date, rezolvarea unor probleme de concurență.

4.2. Implementarea aplicației software a sistemului 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 rolul de stocare a datelor utilizate de către program. În general aplicațiile impelemntează clase care se ocupă de treaba din acest nivel.

Inainte 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 va fi implementată aplicația, iar următorul pas este implementarea ei.

4.2.1. Microsoft.NET

Începand cu anul 2002 tehnologia. NET, dezvoltată de către Microsoft este o platform de calcul care simplifica dezvoltarea aplicatiilor, în special al 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 programare, 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 sa minimizeze desfășurarea software-ului si 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 variatelor tipuri de aplciații, cum sunt aplicațiile Web-based și aplicațiile Windows-based.

Această platformă oferă noi servicii foarte puternice, un nou format binar independent de procesor, noi limbaje, extensii pentru limbajele vechi, dar și alte componente care ajută în dezvoltarea aplicațiilor.

Caracteristicile principale ale platforei .NET sunt urmatoarele:

Este un framewoek 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. Astfel 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 in 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 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# 4

Limbajul C# este un limbaj simplu modern, orientat pe obiect conceput pentru a dezvolta aplicații care să ruleze pe platform .NET Framework. Este un limbaj “simplu” și 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ări, C# se adaptează, prin permiterea programării structurate, modelată și orientată-obiect.

Principiile de bază ale programării pe obiecte (ÎNCAPSULARE, MOȘTENIRE, POLIMORFISM) sunt elemente fundamentale ale programării C#. În mare, limbajul moștenește sintaxa și principiile de programare din C++. Sunt o serie de tipuri noi de date sau funcțiuni diferite ale datelor din C++, iar în spiritul realizării unor secvențe de cod sigure (safe), unele funcțiuni au fost adăugate (de exemplu, interfețe și delegări), diversificate (tipul struct), modificate (tipul string) sau chiar eliminate (moștenirea multiplă și pointerii către funcții). Unele funcțiuni (cum ar fi accesul direct la memorie folosind pointeri) au fost păstrate, dar secvențele de cod corespunzătoare se considerã ”nesigure”.

O aplicație C# este formată din una sau mai multe clase, grupate în spații de nume (namespaces). Un spațiu de nume cuprinde 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. În cadrul aceluiași spațiu de nume poate apărea definiția unui alt spațiu de nume, caz în care avem de-a face cu spații de nume imbricate. O clasă poate fi identificată prin numele complet (nume precedat de numele spațiului sau spațiilor de nume din care face parte clasa respectivă, cu separatorul punct).

O clasă este formată din date și metode (funcții). Apelarea unei metode în cadrul clasei în care a fost definită aceasta presupune specificarea numelui metodei. Apelul unei metode definite în interiorul unei clase poate fi invocatã și din interiorul altei clase, caz în care este necesară specificarea clasei și apoi a metodei separate prin punct.

Pentru a facilita cooperarea mai multor programatori la realizarea unei aplicații complexe, există posibilitatea de a segmenta aplicația în mai multe fișiere numite assemblies. Într-un assembly se pot implementa mai multe spații de nume, iar părți ale unui aceeași spațiu de nume se pot regăsi în mai multe assembly-uri. Pentru o aplicație consolă sau pentru aplicație Windows de altfel, este obligatoriu ca una (și numai una) dintre clasele aplicației să conțină un „punct de intrare” (entry point), și anume metoda (funcția) Main.

4 http://tminfo.ro/upload/files/410682583Manual_final.pdf, Programarea Orientatã pe Obiecte și Programarea Vizualã cu C# .Net

4.3. CONCLUZII

Sistemul informatic este specializat pe asistarea managerului din cadrul unei firme pentru gestionarea clienților și a comenzilor acestora, adică a departamentului de vânzări din cadrul acestei firme. Sistemul efectuează operații precum culegerea, verificarea, stocarea, transmiterea și prelucrarea automată a datelor, care în prezent sunt nu exista în cadrul întreprinderii.

Aplicația este la stadiul inițial de proiectare, fiind mai mult un concept al unui sistem informatic mare. Nu este foarte complexă, putând fi adaugate îmbunătățiri pentru alte informații de care departamentul are nevoie. Aplicația poate fi un punct de dezvoltare pentru noi funcționalități, dar rulează foarte bine chiar și în acest stadiu.

Ca și concluzie finală, sistemul realizat este un pas important în cadrul dezvoltării departamentului de vânzări, aducând o îmbunătățire majoră la performanța managerului acestui departament, totodata neavând costuri mari de dezvoltare și întreținere.

BIBLIOGRAFIE

[1] Conger David, Programarea în C#, editura B.I.C. ALL 2003

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

[2] F. Ionescu, Baze de date relationale si aplicatii, Editura Tehnica, Bucuresti, 2004;

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

[3] Fusaru Doina – Arhitectura bazelor de date – Mediul SQL, Ed. Fundației România de Mâine, 2009

[4] Guțuleac E., Ingineria Programării, Universitatea Tehnică a Moldovei, Chisinău 2011

[5] Lungu I., Gh. Sabău, M. Velicanu, M. Muntean, S. Ionescu, E. Posdarie, D. Sandu, Sisteme informatice. Analiză, proiectare și implementare, Editura Economică, București 2003

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

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

[8] T.Connolly, C.Beg, A.Strachan – Baze de date – proiectare, implementare, gesionare, Editura Teora, Bucuresti, 2001;

[9] http://tminfo.ro/upload/files/410682583Manual_final.pdf, Programarea Orientatã pe Obiecte și Programarea Vizualã cu C# .Net

[10] http://www.seap.usv.ro/~sorinv/PSI.pdf