Sistem Informatic Pentru Gestiunea Activitatilor Unei Scoli de Fotbal

CAPITOLUL 1. INTRODUCERE

Tema proiectului

Tema aleasă de mine pentru acest proiect reprezintă crearea unui sistem informatic cu baze de date și gestiunea acestuia prin intermediul unei aplicații dezvoltate pe baza tehnologiei .NET, cu ajutorul căreia am creat o interfață grafică care facilitează manipularea datelor.

Interfața va fi realizată în WindowsFormsApplication, cu ajutorul mediului de dezvoltare Visual Studio 2010. Limbajul de programare folosit la realizarea aplicației este limbajul C#, un derivat al limbajului C++, care are ca și caracteristică principală faptul că este orientat pe obiecte.

Baza de date va fi una complexă, bazată pe mai multe tabele cu legături între ele, va fi creată în Management Studio 2012 și gestionată cu ajutorul serverului produs de către Microsoft, numit Microsoft SQL Server 2012.

Scopul proiectului

Scopul acestui proiect constă în proiectarea și dezvoltarea unui sistem informatic pentru gestiunea unei școli de fotbal deoarece este importantă urmărirea evoluției tinerilor fotbaliști în timp pentru a asigura o rată cat mai mare de succes producerii a unor jucători de calitate, acest lucru fiind direct proporțional și cu creșterea veniturilor din vânzarea acestora.

Fiind și eu un pasionat al acestui sport, și chiar practicându-l o perioadă de 10 ani, am observat dificultatea antrenorilor de a avea o evidență clară și concisă a fiecărui jucător, deoarece în fiecare an numărul copiilor care se înscriu în cadrul unui club este tot mai mare. Astfel, am decis să dezvolt această aplicație prin care să se poată stoca, introduce și accesa datele cât mai simplu și într-un timp cât mai scurt.

Strângând informații de la mai multe persoane cu o experiență vastă din acest domeniu și fiind implicat activ timp de câțiva ani am convenit asupra funcționalității acestui sistem informatic atât la nivel de sportiv cât și la nivel de grupă.

Astfel, mai întâi de toate, trebuie să existe o evidență a fiecărui sportiv care s-a înscris în club, aceasta trebuind să conțină :

-datele personale

-fișa medicală

-teste fizice

-performanțele sezonului curent

Este necesar să avem și o evidență la nivel de grupă, deoarece fiecare jucător trebuie să fie la categoria corespunzătoare de vârstă, aceasta ajutând la crearea statisticiilor în funcție de performanță și dezvoltare.

La fel de necesară este și o evidență a antrenoriilor care să conțină datele personale și de contact ale acestora împreună cu grupa pe care o antrenează.

Mai trebuie să avem și o evidență a meciurilor deoarece avem nevoie de un istoric al acestora pentru fiecare grupă. Este necesar să cunoaștem data disputării partidei, locația și nu în ultimul rând rezultatul.

Sistemul informatic și informațional

Sistemul informațional este alcătuit din ansamblul informațiilor interne și externe folosite în cadrul organizației, dar și datele care au stat la baza obținerii lor, procedurile și tehniciile de obținere și difuzare a informațiilor, împreună cu personalul implicat în culegerea, transmiterea, stocarea și preluarea datelor .

Într-un sistem informațional se pot evidenția două mari componente:

– o componentă pentru stocarea informațiilor ;

– o componentă pentru prelucrarea informațiilor;

Principalele funcții pe care un sistem informațional trebuie să le îndeplinească sunt:

– colectarea de informații de la sistemele operaționale și decizionale, dar și informații provenite din mediul extern sistemului;

– memorarea acestor informații și a informațiilor provenite din prelucrarea lor;

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

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

Folosirea echipamentelor hardware și a produselor software pentru organizarea și administrarea detelor și a informațiilor, adică în mare informatizarea activității unei organizații, definește conceptul de sistem informatic .

Un sistem informatic complex poate fi descompus în mai multe subsisteme, care la rândul lor pot fi descompuse în aplicații destinate unor anumite categorii de utilizatori, iar aplicațiile la rândul lor pot fi construite pe baza a unuia sau mai multor programe scrise în diverse limbaje de programare.

Capitolul 2. Analiza sistemului informațional

2.1 Analiza datelor – diagrama entități – relații (ERD) la nivel de entități

Pentru realizarea unui sistem informatic cu baze de date, în primul rând avem nevoie de o analiză conceptuală a datelor și de crearea unui model conceptual(schemă conceptuală) prin care ni se transpun vizual legăturile care au loc în respectivul sistem, mai precis relațiile dintre date.

În această etapă datele trebuiesc supuse unei analize care are ca obiectiv identificarea naturii acestora și modul lor de utilizare. În urma acestei analize, datele vor fi grupate în grupuri logice în funcție de nevoia de procesare a acestora, ulterior realizându-se legăturile între aceste grupuri. Aceste legături stabilite între grupuri se mai numesc și relații.

Un model conceptual bine structurat, facilitează ulterior implementarea și dezvoltarea aplicațiilor sau a bazelor de date. Totodată o schemă conceptuală bine structurată face posibilă o vizualizare completă în ansamblu a sistemului informatic.

Proiectarea conceptuală a unei baze de date are rolul de a construi un model care să reconstituie perfect modul în care beneficiarul are acces la informație dar și modul în care acesta o utilizează. Aceasta este independentă față de implementarea fizică a aplicației, după denumire specificându-se că această proiectare este doar la nivel de concept. Pentru implementarea fizică este întotdeuna nevoie de o schemă conceptuală, deoarece relațiile și legăturiile dintre grupurile logice trebuie să fie prestabilite, aplicția trebuind să urmeze întocmai schema atasată acesteia.

Modelul entitate – relație

Modelul entitate-relație este un model conceptual care reprezintă mulțimea de entități și relațiile (asocierile) dintre aceste entități. Principalele concepte folosite pentru construcția acestei diagrame sunt: entitatea, legăturile, cardinalitatea și atributul.

Modelul E-R a fost introdus de către Chen în 1976 și constituie o abordare de tip grafic a proiectării unei baze de date, fiind adoptat de comunitatea științifică precum și de producătorii de software în domeniul respectiv datorită simplității și expresivității sale.

Această metodă este des folosită în proiectarea bazelor de date complexe, care necesită o mare atenție din punct de vedere structural și relațional, facilitând modelarea acestora prin intermediul unor conceptelor amintite mai sus.

Întreaga structură logică a unei baze de date se poate reprezenta grafic cu ajutorul diagramelor ER, unde se pun în evidență entitățiile și legăturiile dintre acestea. Elementele grafice care fac parte din structura unei astfel de diagrame ER sunt:

Dreptunghiurile, care exprimă la nivel logic entitățiile

Liniile, care reprezintă legăturiile sau relațiile dintre entități

Entitatea

Entitatea modelează obiecte sau clase de obiecte concrete dar și abstracte care au o structură concretă și independentă, putând fi identificată în mod unic, și care au o colecție de date înregistrate (informații). O entitate poate să reprezinte atât obiecte fizice, cum ar fi persoane, meciuri, fișe medicale sau locuri dar și obiecte intangibile precum statistici, performanțe sau comenzi.

Figura 2.1 Reprezentare grafică pentru entitate

Spre exemplu, la un meci trebuie să participe o grupă. O grupă este formată din mai mulți jucători. Fiecare grupă trebuie să aibă un antrenor. Entitățile acestui sistem sunt meciul, grupa, jucătorii și antrenorul. Aceste entități sunt in relație, acest lucru fiind reprezentat prin legături. Acest model ER se poate reprezenta grafic astfel:

Figura 2.2 Relația între entități

În identificarea și reprezentarea unei entități trebuie să ținem cont de faptul că fiecare entitate trebuie să aibă un nume specific, unic (nu pot exista două entități cu aceiași denumire) iar o entitate trebuie sa conțină suficiente detalii astfel incât sa fie explicită, acest factor contribuind la o simplificare a sistemului în sensul că vor fi mai usor de observat legăturiile si detaliile. Un alt aspect de care trebuie să ținem cont la reprezentarea unei entități este denumirea acesteia, care se face printr-un substantiv reprezentativ. Nu orice obiect din sistem poate să reprezinte o entitate.

De exemplu nume_jucător sau id_jucător nu pot fi entității. Ele sunt doar atribute pentru entitatea Jucători.

Asocierea

Asocierea este o legatură nedirecționată între entități, acestea din urmă numindu-se și participanți. Numărul participanților dintr-o asociere dau și gradul acesteia. De exemplu participă este o asociere între entitățile Grupă și Meci.

Figura2.3 Reprezentare asociere.

Ca și in cazul entităților, și asocierile trebuie să se supună anumitor reguli. După cum am observat și în exemplul de mai sus, legăturile se denumesc prin verbe. În cadrul unui sistem pot exista mai multe legături cu aceeași denumire însă nu între aceleași două entități.

O altă regulă, este faptul că între două entități putem avea una sau mai multe legături.

Cardinalitatea

Cardinalitatea unei asocieri (relații) indică numărul minim sau maxim de instanțe din fiecare entitate care poate participa la asociere. Aceasta poate fi de trei feluri: unu-la-unu, unu-la-mulți, mulți-la-mulți.

-unu-la-unu ( 1 : 1) , reprezintă faptul că o instanță a unei entități participă în relație cu o instanță a altei entități.

Figura 2.4 Cardinalitate 1 : 1

-unu-la-mulți ( 1 : n) , reprezintă faptul că o instanță a unei entități participă în relație cu mai multe instanțe ale altei entități.

Figura 2.5 Cardinalitate 1 : n

-mulți-la-mulți (m : n), mai multe instanțe ale unei entitați participă la relație cu mai multe instanțe ale altei entități.

Figura 2.6 Cardinalitatea m : n

După cum aminteam anterior entitățile se vor reprezenta prin dreptunghiuri, conținând sau nu atribute, legăturile dintre ele prin linii, specificându-se cardinalitatea acestora. Toate aceste elemente reprezintă o diagramă de tip Entitate-Relație.

Pentru sistemul nostru, vom reprezenta entitățile Jucători, Grupa, Antrenori, meci, date_jucător, performanțe_jucător și fișa_medicală. Pentru acestea vom stabili legăturile dintre ele și cardinalitatea acestora.

Figura 2.7 Diagrama entități – relații (ERD) la nivel de entități

2.2 Analiza proceselor – Diagrama de modelare a proceselor (Business Process Model)

Următoarea etapă în relizarea proiectului constă în analizarea proceselor incluse în sistemul informatic descris. După analiza la nivel de entități și relații, concretizată prin diagrama ER (Figura 2.7) se trece la o analizare la nivel de procese și evenimente din cadrul sistemului și a factorilor care le determină. Această analiză se poate reprezenta tot prin intermediul unei diagrame, respectiv Diagrama procesului de afaceri (Business Process Model).

Limbajul standard folosit în scopul construcției unei diagrame a procesului de afaceri este UML(Unified Modeling Language). Pe lângă standardul acestui limbaj mai există încă două așa-zise extensii UML care facilitează și mai mult construcția procesului de afaceri, acestea din urmă fiind BPMN(Business Process Modeling Notation) și standardul Eriksson-Penker.

Pentru modelarea proceselor de afaceri am folosit standardul Eriksson-Penker care ne oferă un suport sugestiv de comunicare și vizualizare a procesului de afaceri și a informațiilor necesare, așa cum este el descris și reprezentat în Enterprise Architect, iar în continuare voi descrie pictogramele și tehnologia utilizată, conceptele și modul în care le-am aplicat în modelul procesului de afaceri.

Un proces de afaceri este alcătuit dintr-o colecție de activități și informații care au ca scop final producerea unui rezultat. Prezintă o ordine riguroasă cu date de intrare bine definite, un rezultat concret și la fel de bine definit, cu un început și un final. Acesta poate fi considerat ca și o structură de bază pentru aplicația software a sistemului informatic.

Componentele unui proces de afaceri sunt diagrame simple, cu un mic set de elemente grafice, principale componente fiind:

actorul

evenimentul

procesul

scopul procesului

intrări

ieșiri sau rezultatul procesului

informații auxiliare

resurse

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 reprezentati sub forma unor mici personaje având propriul său nume.

Figura 2.8 Reprezentarea grafică a unui actor

Procesul

Procesul este descris ca și o activitate cu un scop bine definit, care în urma unor date de intrare sau condiții inițiale obținem un rezultat. Pentru a ajunge la rezultat, procesul poate folosi mai multe resurse, interne sau externe. Grafic, un proces se poate reprezenta printr-o sageată cu numele procesului scris în interior. Un exemplu pentru sistemul nostru, este procesul de testare a aptitudinilor fizice a jucatorilor, numit Teste fizice.

Figura 2.9 Reprezentarea grafică a procesului Teste fizice

Evenimentul declanșator al procesului

Este acel eveniment care duce la startul activității procesului, elementul declanșator. Evenimentul poate fi reprezentat prin doua feluri de pictograme, una indicând declanșarea evenimentului iar cealaltă rezultatul evenimentului. De regulă este descris printr-un verb.

Evenimentul pentru procesul nostru, Teste fizice, este prezență jucător, reprezentat spre exemplificare prin ambele feluri de pictograme.

Figura 2.10 Reprezentarea evenimentului Prezență jucător

Scopul procesului

Fiecare proces de afaceri trebuie să aibă un scop bine definit. Acesta reprezintă motivul pentru care sistemul funcționează și trebuie să fie exprimat în termenii cei mai potriviți care arată felul în care acest proces aduce beneficii pentru sistem și felul în care el satisface nevoile afacerii. În cadrul diagramei, scopul se leaga de proces printr-o linie punctată.

Pentru procesul de afaceri Teste fizice este Verificarea competentei fizice și este reprezentat în figura următoare:

Figura 2.11 Reprezentarea grafică a scopului

Informații auxiliare

Pentru ca un proces să își poată îndeplini scopul el are nevoie de informații auxiliare care au menirea de a aduce completări acestuia. Informațiile pot veni din surse externe, de la clienți sau pot fi chiar rezultatul unor alte procese. Acestea nu sunt consumate în timpul procesului, deoarece nu servesc ca și resurse pentru proces.

Grafic, informațiile se reprezintă prin căsuțe care se leagă de procese printr-o linie punctată care conține textul <<supply>>.

Resurse

O resursă este o intrare în proces, care spre deosebire de informație poate fi consumată sau modificată în timpul prelucrării. Grafic, resursele sunt reprezentate printr-un dreptunghi, în interiorul căruia se află numele resursei. Legarea de proces se face printr-o săgeată intreruptă, care conține textul <<input>>.

Pentru procesul nostru Teste fizice avem ca resursă setul de probe care ne ajută la testarea fizică a jucătorilor. Resursa Probe este reprezentată grafic în următoarea figură:

Figura 2.12 Reprezentarea resursei Probe .

Ieșirile sau rezultatul procesului

Ieșirile sunt acțiunile și informațiile care rezultă din terminarea activității procesului. Un proces poate avea una sau mai multe ieșiri utile pentru afacere, iar această ieșire poate fi un raport, un obiect fizic sau o transformare a materiei prime într-un produs finit.

Ieșirea pentru procesul nostru o reprezintă rezultatele probelor de control pentru verificarea competenței fizice, si este reprezentată grafic astfel:

Figura 2.13 Reprezentarea ieșirii Rezultate probe .

Pe baza acestor elemente descrise anterior, putem reprezenta grafic o diagramă a procesului de afaceri pentru procesul sistemului nostru informatic, Teste fizice.

Figura 2.14 Diagrama BPM pentru Teste fizice.

O altă activitate importantă pentru o școală de fotbal o reprezintă meciul. Pentru ca un meci să aibă loc este nevoie în primul rând de un teren de fotbal, adică o locație, de participarea echipelor (grupa respectivă de juniori și echipa adversă), de prezența antrenorului grupei respective și nu în ultimul rând prezența arbitrilor, care vor întocmi o foaie de arbitrj. Scopul acestui proces este de a verifica aptitudinile jucătorilor individul și la nivel de echipă dar și acomodarea acestora cu competițiile pentru acumularea experienței necesare.

Ca rezultat final al întregului proces vom avea desfășurarea meciului. Procesul Meci se poate vedea reprezentat în figura următoare:

Figura 2.15 Diagrama procesului de afaceri pentru procesul Meci.

Un alt exemplu de proces funcțional de afaceri îl reprezintă colectarea datelor în scopul creeri unui istoric pentru fiecare jucător în parte, pentru a avea o evidență despre progresul său în timp sau pentru a deține datele și performanțele curente. Acest proces foloseste ca și resursă rezultatul unui alt proces, resprectiv Teste fizice. Pe langă aceasta mai avem resurse precum fișa medicală, date personale sau performanțe. Rezultatul final al procesului va fi evidența jucătorului.

Figura 2.16 Procesul de Colectare date.

Capitolul 3. Proiectarea sistemului informatic

Pe baza analizei conceptuale din capitolul anterior dar și pe baza cerințelor sistemului informatic se realizează proiectarea sistemului. Această proiectare se face în doua etape: proiectarea bazei de date și proiectarea aplicației software atașată sistemului informatic.

În faza de proiectare a bazei de date se urmărește descrierea atributelor fiecărei entitați și legaturile dintre acestea. Acest lucru se va realiza îmbunatațind diagrama relații-entități de la faza de analiză.

Proiectarea aplicației software pentru sistemul informatic descris are ca scop principal stabilirea arhitecturii aplicației. Se urmarește modul în care datele sunt gestionate de către aplicație, dar și modelarea principalelor procese și stări ale aplicației, mai pe scurt modul de funcționare al acesteia și reacția la diferitele cerințe venite din partea utilizatorului.[1].

Proiectarea bazei de date – Diagrama entități-relații la nivel de atribute

Entitatea poate fi un obiect, un lucru, eveniment sau o persoană care are o semnificație pentru sistemul informatic, și pentru care este necesar să colectăm, să introducem și să memorăm date. O entitate poate să fie un obiect real precum o persoană sau poate să fie o activitate precum un meci sau o comandă online.[1].

Proiectarea bazei de date a sistemului informațional sau realizarea design-ului logic al acesteia constă în transformarea schemei conceptuale realizată în cadrul analizei bazei de date (vezi Figura 2.7) într-o schemă a bazei de date care trebuie să fie funcțională în sistemul de gestiune specific. Transformarea acestui modelului conceptual înseamnă stabilirea unor detalii suplimentare care ajută la dezvoltarea proiectului.

Pentru a obține schema logică a sistemului, pornind de la schema conceptuală reprezentată în cadrul modelului entitate-relație, este necesară reprezentarea entităților, atributelor și a relaților dintre ele sub formă de tabele relaționale detaliate.

Astfel, în cazul trecerii de la o schemă conceptuală la o schemă logică, funcțională, au loc niște modificări:

– o entitate devine un tabel.

– legătura dintre entități se implementează cu ajutorul perechilor de chei primară – straină.

– o cheie a unei entități poate fi un atribut sau un set de atribute.

– atributul dă denumirea unei coloane din tabelul entității.

Pentru a descrie o entitate avem nevoie de atribute. Atributele sunt detalii care ajută la identificarea sau exprimarea stării unei instanțe a entitații descrise. Fiecare entitate are atribute specifice, care trebuiesc definite și memorate, în scopul realizarii unei descrieri cât mai amănunțite și care să ofere originalitae entității.

Spre exemplu, pentru entitatea Jucatori avem ca și atribute id_jucator, nume, prenume, CNP, adresa, localitate, judet, nr_telefon, e-mail, data_nasterii, id_grupa. Acestea au rolul de a descrie fiecare jucător în parte, și să dea informații despre acesta. Atributele se vor scrie sub numele entității.

În figura următoare, se prezintă reprezentarea grafică a entității descrise mai sus împreuna cu atributele acesteia.

Figura 3.1

După cum am văzut în capitolul anterior în reprezentarea diagramei entități-relații, pentru sistemul nostru informatic avem șapte entități descrise cu relațiile dintre ele. Pentru fiecare dintre acestea trebuie să stabilim caracteristicile, adică atributele prin care se descriu.

Entitatea principală a acestui sistem și cea în jurul căreia se definesc celelalte entități este entitatea jucatori descrisă mai sus și reprezentată în Figura 3.1.

Celelate entitații descrise în sistem sunt: meci, Antrenori, performante_jucator, date_jucator, fisa_medicala și grupa.

Fiecare entitate are atașat câte un set de atribute, astfel că în continuare le vom analiza pe fiecare în parte. Astfel entitatea meci are ca și atribute id_meci, codul unic pentru fiecare meci în parte, id_grupa, codul unic al grupei care participă la meciul respectiv, id_antrenor

( la fel ca și în cazul grupei), data, locatia și scor necesare pentru a avea o evidență concretă a meciului.

Entitatea Antrenori este oarecum asemănătoare cu entitatea jucatori deoarece se stochează datele personale ale antrenorilor. Ca și în cazul jucatorului, pentru antrenor vom avea un cod unic de înregistrare, id_antrenor, nume, prenume, adresa etc. Singura legatură a antrenorului este participarea la meci.

Figura 3.2 Reprezentare meci, Antrenori.

Celelate entități și anume date_jucator, performante_jucator, fisa_medicala, grupa, se află într-o strânsă legătura cu entitatea jucator, deoarece acestea ajută la o descriere aprofundată a jucătorului din punct de vedere al performantelor înregistrate și a poziței sale în club, o descriere a situației din punct de vedere fizic și medical și nu în ultimul rând apartenența la un grup a acestuia.

Grupa va fi caracterizată prin codul unic prin care se oferă autenticitate fiecărei grupe, respectiv id_grupa, de numele acesteia reprezentat prin atributul denumire, și de categoria de vârstă cuprinsă între două valori varsta_minima și varsta_maxima.

Prin entitatea date_jucatori am încercat să creez o evidență a jucătorului din punct de vedere al rolului în echipă. Scopul acesteia este primirea de informații despre numărul de pe tricou din cadrul grupei al jucătorului, poziția acestuia în teren, piciorul de bază cu care sportivul lovește mingea mai bine sau calitățiile cum ar fi viteză, tehnică, joc aerian etc…

Atributele care descriu aceste informații sunt: id_jucator, id_grupa, pozitie, nr_tricou, picior_de_baza și calitati.

Performante_jucator este entitatea care colectează date despre performanțele individuale ale fiecărui jucător. Se prezintă sub forma unei statistici unde sunt stocate numărul de meciuri jucate (nr_meciuri_jucate), numărul de goluri reușite în meciurile jucate (goluri), numărul paselor de gol (assist) sau numărul de cartonașe roșii sau galbene încasate pe parcursul sezonului pană la ultimul meci jucat (cartonase_galbene, cartonase_rosii). Performanțele unui jucător sunt pentru un singur sezon, astfel că la începerea unui nou sezon de campionat, performanțele vor începe din nou de la zero, iar cele din sezonul recent terminat vor fi memorate, creându-se astfel un istoric pentru fiecare jucător. Pe langă atributele descrise mai sus, vom avea evident și id-ul jucătorului și al grupei din care face parte.

Ultima entitate descrisă a acestui sistem informatic este fisa_medicala care conține setul de probe și teste fizice pentru un jucător, dar și viza medicală necesară pentru dovada faptului că un sportiv este apt din punct de vedere medical. O altă caracteristică a fișei medicale este data la care au fost făcute testele fizice și examinarea medicală. Tot în cadrul acestei entități avem date despre înălțimea și greutatea fiecărui sportiv specificându-se și unitatea de masură pentru acestea (inaltime_cm, greutate_kg).

Celelalte atribute componente ale fișei medicale sunt: id_jucator, viteza_50m, viteza_100m, rezistenta_2000m și viza_medicală.

Figura 3.3 Reprezentare fisa_medicala, date_jucator, performante_jucator, grupa.

Cheia unei entități

O cheie a unei entități poate fi un atribut sau un set de atribute care ajută la o identificare unică a unei instanțe a aceleiași entități. Funcția principală îndeplinită de o cheie este aceea de a face diferența între două randuri ale tabelului provenit din aceeași entitate.

De exemplu, în cazul nostru, pentru fiecare jucător din școala de fotbal avem un cod de înregistrare unic, numit id_jucător. Pentru entitatea Jucători acest cod unic este cheia entității. Numele și prenumele nu ar putea constitui unicitatea deoarece doi sau mai mulți jucători ar putea avea același nume și prenume. În acest caz, id-ul asigură unicitatea jucătorului.

Figura 3.4 Exemplificarea cheii unice id_jucător.

După modul de stabilire a relaților avem două tipuri de chei relaționare și anume:

cheie primară – este folosită pentru identificarea în mod unic a unei instanțe din cadrul unei relații. Cheia primară trebuie să respecte anumite condiții precum nepermiterea valoriilor nedefinite pentru atributele cheii sau nepermiterea modificării valorii unui atribut al cheii în urma operațiilor de actualizare. În procesul de selectare a unei chei primare trebuie să ținem cont de necesitatea ca numărul de atribute ale cheii să fie cât mai mic posibil. Astfel, se va selecta ca și cheie primară cheia care are toate atributele sale bine definite și un număr cat mai mic al acestora.

În cadrul reprezentării entității, atributul folosit ca și cheie primară va avea în fața sa desenată o cheie simbolică. Pentru exemplul de mai sus în care am exemplificat cheia primară id_jucator, voi face o reprezentare grafică pentru a evidenția modul în care se simbolizează aceasta:

Figura 3.5 Reprezentarea grafică a simbolului cheii primare

cheie străină – formată dintr-un atribut sau un set de atribute al unei relații care se potrivește cu cheia primară a unei alte relații.

De exemplu avem entitățiile jucatori și fisa_medicala. Cheia primară a entității jucatori este id_jucator. Jucatori se va lega de fisa_medicala prin intermediul cheii id_jucator, deoarece acest atribut se gasește și în interiorul fișei, acesta din urmă devenind cheie străină ( id_jucator din jucatori –cheie primară, id_jucator din fisa_medicala – cheie străină ).

Figura 3.6 Reprezentarea legăturii cheie primară – cheie străină între entitățiile fisa_medicala și jucatori.

Transformarea relațiilor.

În funcție de cardinalitatea legăturilor dintre entități avem mai multe criterii de transformare a relațiilor:

– Transformarea legăturii 1:1 . În acest caz relațiile 1:1 se reprezintă prin chei străine . Poziția cheii este dată de cardinalitatea minimă a legăturii .

– Transformarea legăturii 1:N . Această legătură devine cheie străină pusă în tabelul care se află în partea ”N” a relației .

– Transformarea legăturii N:M . Acest tip de relație se transformă prin crearea unui nou tabel special, numit tabel asociativ, tabel conține două chei străine pentru cele două tabele asociate . Cheia primară a acestui tabel este compusă din aceste două chei străine plus alte coloane adiționale, dar acestea sunt opționale. Astfel această relație putem considera că se desparte în două relații 1:N, tabelul asociativ fiind în aceste două relații de partea ”1”. [2].

Transformarea atributelor.

Transformarea atributelor se face după următoarele reguli:

– Atributele unei entități se transformă în coloane în tabelul provenit din aceasta.

– Atributele unei relații 1:1 sau 1:N vor deveni coloane ale tabelului care conțin cheia străină.

– Atributele ale unei relații N:M vor deveni coloane ale tabelului asociativ.

– Atributele multivaloare ale unei relații 1:1 sau 1:N vor deveni tabele dependente de tabelul care conține cheia străină, iar atributele repetitive ale unei relații N:M vor deveni tabele dependente de tabelul asociativ corespunzător relației. [2].

Pe baza acestor reguli de transformare, a descrieri amănunțite a entităților la nivel de atribute dar și a evidențierii legăturilor dintre ele putem realiza schema logică de proiectare a bazei de date. Odată cu realizarea acestei diagrame, se termină și prima etapă în procesul de proiectare a sistemului informațional definit în capitolul anterior.

Figura 3.7 Proiectarea bazei de date relaționate.

Proiectarea aplicației software

Procesul de proiectare a aplicației software atașată sistemului informatic descris în capitolul anterior are ca scop pregătirea sistemului pentru a face față tuturor situaților și activităților posibile la care va fi supus pe parcursul funcționarii acestuia. Proiectarea se face pe baza diagramelor UML, prin care se reprezintă fluxurile de date (Data Flow Diagram), cazurile de utilizare a sistemului (Use Case Diagram), activitatea principalelor procese (Activity Diagram), stările prin care trece sistemul (State Machine Diagram) sau secvențele prin care trec procesele din cadrul sistemului (Sequence Diagram).

Diagrama fluxurilor de date (Data flow Diagram)

Diagrama fluxurilor de date (Data flow diagram) este un proces de proiectare independent de tehnologie și reprezintă o modelare a fluxurilor de date din cadrul sistemului informatic și ajută la evidențierea relației logice dintre principalele entități și procese ale acestuia.

Diagrama flux de date prezintă circuitul datelor, structura lor dar și cerințele funcționale ale sistemului descris. Este o metoda excelentă de rezumare și organizare a informațiilor detaliate despre limitele sistemului informatic, a proceselor, a entităților implicate, oferind proiectantului o hartă logică a sistemului informatic . Elementele unei astfel de diagrame conduc direct la designul fizic al sistemului, unde procesele sugerează programe și proceduri, fluxurile de date reprezintă colaborarea dintre ele, iar sursele de date sugerează entități, fișiere și baze de date .

Scopul diagramei fluxurilor de date este de a explicita și nuanța cu preponderență aspecte precum operațiunile prin care trec datele, sursa de proveniență a datelor venite pentru prelucrare, destinația datelor prelucrate sau aspecte legate de legătura dintre prelucrări și activitățiile de stocare a datelor.

Pentru a întocmi diagrama fluxurilor de date pentru sistemul nostru informațional trebuie mai întai să cunoaștem simbolurile folosite în cadrul acesteia, rolul acestora și mai ales regulile după care se aleg acestea. Trebuie să ținem cont și de faptul că legatura dintre fluxurile de date și stocurile de date este întotdeauna unidirecțională.

Simbolurile folosite în cadrul acestei diagrame sunt:

Procesul – este etichetat cu un text care arată în general modul de prelucrare a datelor, iar identificarea se face prin descrierea funcției acestuia.

În figura următoare se va reprezenta grafic procesul de update jucatori, proces prin care se actualizează baza de date Jucatori.

Figura 3.8 Reprezentarea procesului update jucatori.

Fluxul de date – definit de datele care circulă în interiorul sistemului informatic. Se reprezintă prin intermediul unei săgeți care conține numele datelor sau pachetelor de date pe care le transportă.

Figura 3.9 Exemplificarea fluxului de date.

Entitatea externă – poate fi o sursă de date sau un receptor de date. Poate fi reprezentată și de către un alt sistem. Un exemplu de entitate este antrenorul, care colectează date despre jucători dar și emite rezultatele testelor fizice ale jucătorilor.

Figura 3.10 Reprezentarea grafică a entității externe Antrenor.

Stoc de date – este de regulă reprezentat de către baza de date a sistemului și se reprezintă astfel:

Figura 3.11 Reprezentarea stocului de date BD Jucatori.

Un exemplu de diagramă flux de date pentru sistemul nostru informațional descris în capitolul anterior îl reprezintă modul de actualizare a bazei de date, prin intermediul tabelelor aferente acesteia, de către administratorul sistemului informațional. Pentru fiecare bază de date avem atașat câte un proces prin care se actualizează datele. Spre exemplu, administratorul sistemului trimite date către procesul numit Update Jucatori, pe care acesta din urmă le prelucrează. Datele actualizate vor fi mai apoi trimise către baza de date Jucatori unde vor fi memorate. La fel se va întampla și în cazul antrenorilor, meciurilor și a fișelor medicale.

Figura 3.12 Diagrama fluxurilor de date pentru actualizarea bazei de date.

Diagrama fluxurilor de date atașată întregului nostru sistem informațional este exemplificată în figura următoare. Ea respectă întocmai toate cerințele necesare construirii unei astfel de diagrame.

Figura 3.13 Diagrama fluxurilor de date atașată sistemului informatic

Diagrama cazurilor de utilizare (Use Case Diagram)

Această diagramă are ca scop descrierea comportamentului sistemului informatic dând o imagine de ansamblu asupra modului de utilizare a sistemului dar și asupra funcționalităților acestuia. Pe lânga acestea, mai are rolul de a arăta interacțiunea dintre sistem și utilizatori. Așadar, pentru a creea acest model al cazurilor de utilizare trebuie în primul rând identificați actorii, cazurile de utilizare, relațiile dintre ele dar și dintre acestea și actori.

Actorii reprezintă elemente care interacționează cu sistemul, nefiind parte a acestuia. El nu participă propriu-zis la prelucrarea datelor din sistem, el fiind limitat doar la a primi date și introduce date sistemului, astfel acesta poate fi considerat doar ca un generator de evenimente. Un actor reprezintă o clasa și nu o instanță și are acelasi rol ca și o entitate externă din diagramele de flux de date , adică de a interacționa cu sistemul informatic .

Identificarea actorilor trebuie atent studiată și se referă la stabilirea entitățiilor interesate de utilizarea sistemului sau de interacțiunea cu acesta. Astfel, identificarea se face pe baza raspunsurilor la anumite întrebări precum cine va avea nevoie de sistem în munca de zi cu zi? sau cine va folosi funcționalitatea acestuia?

Alte aspecte în identificarea actorilor se vor lega de cine va administra sistemul, cine va fi interesat de rezultate sau ce device-uri hardware vor avea nevoie de sistem. [3].

Reprezentarea grafică a actorului este exemplificată în figura următoare:

Figura 3.14 Reprezentarea actorului.

Cazurile de utilizare – surprind anumite funcționalități ale sistemului, din punctul de vedere al utilizatorului. Cazurile de utilizare arată ce trebuie să facă sistemul informațional și nu modul în care trebuie să o facă. Reprezintă un set de secvențe pe care sistemul le realizează pentru întocmirea unui răspuns către actori. Un caz de utilizare se reprezintă astfel:

Figura 3.15 Reprezentarea cazului de utilizare Update Jucatori

Între cazurile de utilizare există trei tipuri de relații: de includere, de extindere și de generalizare.

Includerea – este o relație prin care un caz de utilizare include comportamnetul unui alt caz de utilizare. Se reprezintă printr-o săgeată întreruptă de la cazul principal către cel inclus.

Figura 3.16 Reprezentarea relației de includere dintre două cazuri de utilizare.

Extinderea – este o relație prin care un caz de utilizare este inserat într-un alt caz, această inserare se realizează doar la îndeplinirea anumitor condiții.

Figura 3.17 Reprezentarea relației de extindere între doua cazuri de utilizare.

Generalizare – este o relație prin care un caz de utilizare moștenește comportamentul unui alt caz de utilizare și îl îmbunătățește

Figura 3.18 Reprezentarea relației de generalizare între două cazuri de utilizare

Un alt tip de relație întâlnită în interiorul diagramelor Use Case este relația de asociere, dintre actori și cazurile de utilizare. Asocierile se reprezintă printr-o linie ce unește actorul de cazul de utilizare respectiv. Această relație este exemplificată în figura de mai jos, unde avem ca si utilizator, administratorul sistemului informațional, iar cazul de utilizare este Update Jucatori.

Figura 3.19 Asocierea.

Diagramele atașate sistemului informatic descris sunt prezentate în imaginile de mai jos. În prima diagramă actorul este reprezentat de către administratorul sistemului informatic, care se ocupă cu update-ul bazei de date.

Figura 3.20 Diagrama Use Case 1.

În a doua diagramă a cazurilor de utilizare este prezentat ca și actor Antrenorul care actualizează datele sale personale, înregistrează anumite rezultate provenite din testele fizice și vizita medicală a jucătorilor sau realizează statistica meciurilor.

Figura 3.21 Diagrama Use Case 2.

Diagrama de activități a sistemului (Activity Diagram)

În continuarea proiectării sistemului informatic este necesar să descriem și să explicităm cazurile de utilizare identificate ale sistemului. Diagramele de activitate definesc activitățile și responsabilitățile elementelor care fac parte din sistem.

În mod normal, o diagramă de activitate ilustrează evenimentele din cadrul unui caz de utilizare sau proces care se desfășoară în cadrul sistemului informatic. O diagramă de activitate poate fi folosită în scopul modelării comportamentului intern al unei metode, pentru analiza interacțiunii dintre activități în cadrul unui caz de utilizare sau pentru a reprezenta modul de organizare a mai multor cazuri de utilizare dar și relațiile dintre acestea. De asemenea diagrama de activități se concentrează doar asupra activitățiilor și nu asupra acțiuniilor declanșatoare ale acestora.

Elementele care fac parte dintr-o diagramă de activitate sunt:

-activitatea

-acțiunia

-punct inițial

-punct final

-tranziția

-punct de decizie

Activitatea este definită ca fiind seria de acțiuni reprezentate în diagramă. Pe scurt, activitatea este considerată întraga diagramă, de aceea nu are o notație specifică.

Acțiunea este reprezentată de către un singur pas în diagramă, și nu va mai fi detaliată. Acțiunea este o instanță care va fi folosită doar în cadrul activității în care este inclusă. Perioada de viață a unei activități începe în momentul în care toate condițiile de funcționare îi sunt satisfăcute, și își termină ciclul în momentul începerii altei activități succesoare ei. Grafic, acțiunea se reprezintă sub forma unui dreptunghi cu colțurile rotunjite.

Figura 3.22 Reprezentarea grafică a unei activități.

Pentru că diagramele de activitate arată modul de desfășurare al unei activități, ele trebuie să aibă un punct de pornire, numit punct inițial, dar și un punct de oprire, punct final.

În cadrul unei diagrame trebuie să avem un singur punct inițial, de la care pleacă o singură tranziție către o acțiune. Spre deosebire de punctul inițial, o diagramă de activitate poate să conțină mai multe puncte finale, deoarece în cazul neîndeplinirii condiților de funcționare ale unei acțiunii, activitatea va fi oprită.

Figura 3.23 Reprezentarea grafică a punctului inițial și a punctului final.

Tranziția din cadrul diagramei arată întotdeauna ordinea de execuție a acțiuniilor din cadrul activității. Reprezentarea grafică se face printr-o săgeată de la precedenta către următoarea acțiune.

Figura 3.24 Reprezentarea tranziției.

Punctul de decizie reprezintă o condiție care afectează continuitatea activității, sau direcția în care va continua aceasta. Spre exemplu pentru ca administratorul sistemului să aibă acces la informații ele trebuie să se logheze. Aici intervine punctul de decizie sau condiția: dacă logarea va fi validată atunci el va avea acces la informații, altfel nu va putea avea acces la sistem.

Figura 3.25 Exemplificarea punctului de decizie.

O activitate importantă în cadrul sistemului nostru informațional descris este editarea performanțelor sportivilor care se modifică în urma fiecărui meci jucat, deoarece prin performanțe înțelegem numărul de meciuri jucate, numărul de goluri marcate, numărul de pase de gol, cartonașe roșii sau galbene pentru fiecare jucător al școlii. Acestă activitate are ca și punct inițial deschiderea aplicției utilizator. Următorul pas îl constituie logarea acestuia, unde intervine blocul decizional validare a logării. Dacă logarea este validă utilizatorul are acces la date, în caz contrar activitatea va fi închisă. Următorii pași fac parte din procesul de editare a valorii performanțelor jucătorilor ( Editare performanțe jucator, Selectare jucător, Vizualizare performanțe….).

Figura 3.26 Reprezentare Diagramă de activitate pentru activitatea de editare a performanțelor jucătorilor.

Alte activității care fac parte din sistem sunt editare date antrenor, editare date jucător, editare meci sau editare fișa medicală. Toate aceste diagrame se bazează pe același principiu de funcționare. În următoarea diagramă se exemplifică activitatea de editare date antrenor.

Figura 3.27 Reprezentare Diagramă de activitate pentru editarea datelor personale ale

antrenorului

Diagrama de stare a tranzițiilor ( State Machine Diagram )

Este folosită pentru a arăta stările prin care trec anumite obiecte, evenimente care determină tranziția de la o stare la alta dar și condițiile pentru realizarea tranzițiilor. Scopul acestor diagrame este de a descrie răspunsul și comportarea diferitelor obiecte la influențe externe dar și de a reprezenta secvențele de stări prin care trec obiectele pe parcursul existenței lor.

Ca și reprezentare, diagrama de stare este la fel ca și cea de activitate doar că în locul acțiunilor se reprezintă grafic stările sistemului. Astfel, componentele unei astfel de diagrame sunt: stările, tranzițiile, punctele de intrare, de iesire și punctele de decizie.

Componentele diagramei se reprezintă grafic identic cu componentele diagramei de acțiune și sunt exemplificate în figura următoare:

Figura 3.28 Reprezentarea componentelor unei diagrame de stare.

La fel ca și în cazul diagramelor de activitate, diagramele de stare se bazează pe același principiu de funcționare pentru procesele noastre de editare date a jucatorilor, antrenorilor, meciurilor sau fișei medicale din cadrul sistemului. Astfel că voi reprezenta grafic doar una dintre aceste diagrame de stare respectiv editare date jucători.

Această diagramă, ca și cea de activitate trebuie să aibă un punct inițial și un punct final. Stările prin care trece evenimentul de editare date jucător sunt: Jucator selectat, Date personale vizualizate, Date personale introduse sau Date personale modificate sau Date personale sterse, Date personale salvate. Tranzițiile sunt reprezentate prin săgeți care conțin și numele tranziției. Punctul de decizie îl reprezintă selectare acțiune, unde se alege operațiunea care va avea loc asupra datelor, de introducere, de modificare sau de ștergere.

Figura 3.29 Diagrama de stare a tranzițiilor pentru editare date personale jucător.

În mod analog se pot reprezenta diagrame de activități pentru operațiunile de editare date antrenori, editare date fisa medicală sau editare date meci.

Diagrama de secvențe ( Sequence Diagram )

Diagramele de secvență analizează și detaliază în mod obișnuit, aspectul temporal al obiectelor și al interacțiunii dintre acestea.

Scopul unei astfel de diagrame este de a creea o idee asupra cum preiau obiectele acțiunea în anumite situații și asupra felului î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 .

Principalele elemente ale unei diagrame de secvențe sunt: obiectele, liniile de viața și mesajele .

Obiectele sunt principalele elemente ale diagramei, și sunt entitățile care în cadrul diagramei intervin în prelucrarea datelor. Grafic, obiectele se reprezintă sub forma unui dreptunghi și sunt plasate orizontal în partea de sus a diagramei.

Figura 3.30 Reprezentarea obiectului în cadrul diagramei de secvențe.

Liniile de viață au rolul de a arăta durata de viață a obiectelor. Ele sunt reprezentate grafic print-un dreptunghi atașat liniilor punctate descendente obiectului.

Figura 3.31 Reprezentarea liniei de viață în cadrul diagramei de secvențe.

Mesajele sunt elementele cu care obiectele comunică între ele. Ele pot sugera apeluri de funcții și pot fi însoțite de condiții asupra trimiterii mesajelor. Grafic, sunt reprezentate prin intermediul unor săgeți care unesc liniile de viață a obiectelor. Denumirea mesajului este scrisă pe săgeată.

Pentru sistemul nostru informatic am ales să reprezint grafic modul de funcționare al acestuia. Ca și obiecte, avem utilizatorul, aplicația software utilizator și baza de date. Astfel, în acest caz utilizatorul trimite un mesaj aplicației prin care cere logarea în sistem. Logarea va fi validată de catre aplicație care trimite răspunsul corespunzător utilizatorului. Daca logarea a fost efectuată utilizatorul poate transmite comanda aplicației. După ce aplicația a primit comanda, verifică conexiunea la baza de date, dacă aceasta este validă, trimite comanda spre baza de date. Comanda poate fi reprezentată de exemplu editarea, stergerea sau modificarea datelor unui jucător, antrenor sau meci. Odată cu efectuarea comenzii în baza de date, vine și răspunsul către aplicație care îl trimite mai apoi spre vizualizare utilizatorului. Diagrama este reprezentată în figura de mai jos.

Figura 3.32 Diagrama de secvențe pentru selectarea unei grupe de juniori.

Capitolul 4. Implementarea sistemului informatic

Implementarea este procesul prin care algoritmul obținut în faza de proiectare este transpus în limbaj de programare. Pentru o realizare cât mai corectă, acest procedeu presupune ca persoana care relizează implementarea să cunoască atat limbajul de programare cât și limbajul folosit în faza de proiectare.

În cazul sistemului nostru informațional implementarea va fi făcută în două etape:

Implementarea bazei de date a sistemului

Implementarea aplicației software atașată sistemului.

4.1 Implementarea bazei de date

Implementarea bazei de date a sistemului informațional presupune transformarea schemei logice realizată în faza de proiectare (vezi figura 3.7) într-o structură fizică eficientă, specifică sistemului de gestiune folosit.

Limbajul SQL

Limbajul SQL ( Structured Query Language ) este unul dintre cele mai puternice și folosite limbje structurale folosite pentru gestionarea, interogarea, definirea sau reactualizarea bazelor de date relaționale.

Ca și structură este considerat a fi un limbaj neprocedural și declarativ, și nu un limbaj de programare. Eficiența sa este poate fi testată la bazele de date de tip client – server.

Implementarea limbajului SQL se poate face având în vedere 3 metode prin care acest lucru se poate realiza :

– apelarea directă care constă în introducerea instrucțiunilor direct din prompter.

– apelarea modulară care foloseste procedeuri apelate de programele aplicației .

– apelarea încapsulată ce conține instrucțiuni încapsulate în codul de program .

Exemple de comenzi SQL sunt: CREATE TABLE, SELECT FROM, REPLACE, DELETE, INSERT TO etc… [4]

Microsoft SQL Server 2012

Pentru implementarea bazei de date am ales sistemul de gestiune al bazelor de date Microsoft SQL Server varianta 2012.

Microsoft SQL Server 2012 este un sistem de gestiune al bazelor de date relaționate produs de compania americană Microsoft Corporation. Este un sistem util pentru companii deoarece suportă baze de date de dimensiuni foarte mari. Limabjul de interogare este SQL.

Datorită faptului că are un model de programare asemănător celui al Windows-ului face ca utilizarea lui să fie mai ușoară, pe lângă faptul că este recunoscut pentru ușurința de instalare și de dezvoltare a aplicațiilor. Acesta permite și lucrul cu documente XML și poate fi interogat cu alte produse software gen servere de web sau e-mail.

Microsoft SQL Sever 2012 oferă avantaje și în realizarea de aplicații business cum ar fi timpul de dezvoltare mai rapid datorită procedurilor stocate, o securitate sporită, eliminarea pierderii de date accidentale sau ușurința recuperarii datelor.

Crearea bazelor de date în Microsoft SQL Server se face cu ajutorul unei unelte grafice de management al acestuia numită Management Studio 2012, și poate fi facută în două feluri: direct cu ajutorul limbajului SQL sau cu ajutorul uneltelor și funcților care generează codul SQL necesar.

Una dintre cele mai importante comenzi este cea de creare a unui tabel. Comanda necesară este comanda CREATE TABLE. Pentru a exemplifica cât mai bine elementele care țin de crearea și definirea principalelor elemente ale unui tabel, în cele ce urmează vom crea tabelul jucatori așa cum este descris în figura 3.1 din faza de proiectare.

Figura 4.1 Crearea tabelului jucatori.

În continuare trebuie setată cheia sau cheile primare a tabelei, dar și cheile străine către alte tabele, dacă există asa ceva. Această operațiune se face cu ajutorul comenzii ALTER TABLE, comanda care dă posibilitatea utilizatorului să modifice elemente din cadrul unui tabel deja creat .

Figura 4.2 Setarea cheilor primare și străine.

Diagrama bazei de date la nivel fizic este alcătuită din reprezentarea tabelelor împreună cu atributele acestora, tipul de dată al atributelor și proprietatea de a fi sau nu nule.

Figura 4.3 Reprezentarea fizică a bazei de date.

Implementarea aplicației software

Înainte de a începe proiectarea, persoanele care se ocupă cu acest lucru trebuie să aibă o imagine de ansamblu și asupra aplicației software, despre cum ar trebui să arate aceasta și ce funcții ar trebui să îndeplinească. Odată ce aceste lucruri au fost clar stabilite, se trece la etapa următoare prin care se aleg tehnologiile care corespund cel mai bine cerințelor și care pot dezvolta aplicația cât mai bine cu putință.

În implementarea aplicației software se disting trei nivele:

nivelul de prezentare care constă în interfața grafică pe care aplicația o prezintă

nivelul logic reprezentat de codul sursă din spatele interfeței, care asigură buna funcționare a aplicației

nivelul de acces la date care va stoca datele utilizate de către program.

Tehnologia folosită pentru implementarea aplicației sistemului informatic este .NET. Aceasta reprezintă un cadru de dezvoltare software care permite realizarea, distribuirea și rularea aplicațiilor de tip desktop Windows sau WEB.

Tehnologia .NET pune laolaltă mai multe tehnologii precum ASP, XML, OOP, SOAP, WDSL, UDDI și limbaje de programare VB, C++, C#, J# asigurând totodată atât portabilitatea codului compilat între diferite calculatoare cu sistem Windows, cât și reutilizarea codului în programe, indiferent de limbajul de programare utilizat.

O altă caracteristică importantă a tehnologiei .NET este că oferă un set comun de biblioteci de clase, set care poate fi accesat din orice limbaj de programare inclus în .NET. De aceea cunoașterea unui singur limbaj de programare din această platformă este de ajuns pentru a scrie codul, deoarece nu există seturi de clase diferite pentru fiecare limbaj.

Limbajul de programare pe care am ales să îl utilizez pentru implementarea aplicației software este C#.

C# este un limbaj orientat pe obiecte, și poate fi considerat simplu din punctul de vedere al numărului de cuvinte cheie din care este alcătuit ( 80 ) și a tipurilor de date predefinite în cadrul lui ( 12 ). Este un limbaj inclus în platforma .NET și a fost dezvoltat de către compania Microsoft pornind de la limbajul C++.

Față de limbajul C++, în cadrul limbajului C# au fost adăugate o serie de tipuri noi de date, pentru scrierea unor secvențe de cod cât mai sigure, au fost adăugate funcții noi precum interfețele sau au fost eliminate elemente precum moștenirea multiplă sau pointerii către funcții.

Fiind un limbaj orientat pe obiecte, elementele fundamentale sunt încapsularea, moștenirea și polimorfismul, iar principalele componente sunt clasele. Acestea sunt organizate în spații de nume ( namespace ).

În cadrul limbajului C# au fost introduse, de către dezvoltatorii acestuia, mai multe clase care au facilitează accesul la date, acestea fiind puse la dispoziția programatorului. Aceste clase sunt în număr de șapte respectiv:

– DbConnection

– DbCommand

– DbDataReader

– DbDataAdapter

– DataSet

– DataRelation

-DataTable

Cele mai importante clase pentru aplicația software a sistemului informatic analizat și proiectat în capitolele anterioare sunt DbConnection și DbCommand.

DbConnection este o clasa care realizează conexiunea cu aplicației cu baza de date. Conexiunea efectivă cu baza de date se realizează cu ajutorul unui șir de conexiune (connection string ), șir stocat în parametrul ConnectionString al clasei DbConnection.

În cadrul aplicației realizate, definirea și realizarea legăturii cu baza de date se face cu ajutorul clasei derivate SQLConnection astfel :

O altă clasă la fel de importantă este clasa DbCommand. Aceasta este clasa care implementează interacțiunea directă cu baza de date. Cu ajutorul obiectelor de tipul DbCommand vor putea fi executate interogările de tip SQL și cam tot ce este legat de comenzile SQL asupra bazei de date.

O comandă SQL care trebuie executată va fi inserată sub forma unui string, care va fi stocat în cadrul variabilei CommandText.

La fel ca și în cazul clasei DbConnection, și aici există clasa SQLCommand, care este o clasă derivată a DbCommand și este folosită în cazul utilizării SQLServer.

Mai sus este definită comanda pentru extragerea tuturor jucătorilor și a datelor acestora din tabelul jucători. Conexiunea la baza de date este asigurată de către obiectul con.

Afișarea rezultatului se va face în DataGridView-ul atașat interfeței grafice.

Capitolul 5. Concluzii

Aplicația Sistem informatic pentru gestiune activităților unei școli de fotbal este proiectată pentru a gestiona eficient activitățile unei școli de fotbal, aceasta atingându-și toate obiectivele propuse.

În țara noastră, softurile de acest gen sunt aproape inexistente, deoarece am observat că nu se prea pune accent pe gestiunea sportului de echipă cum ar fi fotbalul, la nivelul de juniori. Majoritatea școlilor de fotbal sau a cluburilor de junior sunt la nivel local, și nu au suficiente resurse pentru a-și întocmi un astfel de sistem de gestiune.

Principalele avantaje ale acestui sistem informatic ar fi următoarele:

deținerea unui istoric pentru fiecare sportiv înscris în scoala de fotbal, cu evoluția în timp și performanțele acestuia la nivel individual și de echipă

gestionarea cu ușurință a anumitor activități cum ar fi meciuri, statistică meciuri, măsurătorile testelor fizice, vizitele medicale

accesul rapid la date

utilizarea simplă a aplicației software

realizarea simplă a statisticilor pe baza criterilor cerute de către utilizator

ușurarea muncii antrenorilor

Proiectarea bazei de date și implementarea simplă poate ajuta la dezvoltarea ulterioară a aplicației:

Printre primele dezvoltări care pot fi implementate pentru sistemul informatic realizat este dezvoltarea capitolului de securitate și acces diferit la date, capitol pe care nu s-a pus accent în dezvoltarea aplicației până în acest moment.

.Introducerea unor tabele care să aibă ca scop monitorizarea antrenamentelor, participarea jucătorilor și antrenorilor la acestea.

Fiind o aplicație dezvoltată într-un timp relativ scurt și de către o singuă persoană , aceasta are anumite limite. Existența unei documentații tehnice, reprezentată de diagramele prezentate, respectiv disponibilitatea surselor programului atașat sistemului, constituie un avantaj important în scopul facilitării dezvoltărilor ulterioare, dar și mentenanța aplicației existente.

Bibliografie

[1] http://paulierco.ro/wp-content/uploads/2008/02/Design-rezumat.html

[2 ] http://www.scritub.com/stiinta/informatica/baze-de-date/Proiectare-bazelor-de-date31676.php

[3 ] http://cs.upm.ro/_users/cursuri_on_line/CD/IP/UML.HTM

[4 ] http://www.scrigroup.com/calculatoare/sql/Prezentare-generala-SQL23647.php

[5] Ileana Ștefan- Analiza și proiectarea sistemelor informatice,Târgu-Mures,2007

[6] Dorin Lixandroiu, Radu Lixandroiu – Baze de date relaționare, Brașov 2009

[7] Stanciu V. – Proiectarea sistemelor informatice de gestiune, Ed.Cison, Bucuresti 2000

[8] C.J.Date,Baze de Date, Ed. Plus, Bucuresti, 2002

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

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