În calitate de student al „Facultății de Calculatoare și Informatică Aplicată” din cadrul Universității „Tibiscus”, încă din primul an de studenție… [305481]
Cuprins
Introducere
În calitate de student: [anonimizat] „Facultății de Calculatoare și Informatică Aplicată” din cadrul Universității „Tibiscus”, încă din primul an de studenție am conștientizat importanța alegerii unui subiect pentru lucrarea de licență.
În anul al doilea de facultate am studiat materia „Programare orientată obiect”, ocazie cu care am studiat limbajul de programare Java. În anul următor am studiat disciplina „Sisteme de gestiune a bazelor de date”, [anonimizat], unde am avut de efectuat un proiect ce avea ca cerințe dezvoltarea a unei aplicații în limbajul PHP care să acceseze o [anonimizat]-a venit ideea de a realiza și o aplicație în limbajul Java care sa lucreze cu o baza de date MySQL. [anonimizat] o [anonimizat] a devenit ulterior subiectul lucrării mele de licență.
[anonimizat] a crea o aplicație Java care sa fie capabilă să folosească o bază de date MySQL.
Lucrarea este structurată în trei capitole astfel. [anonimizat], dar și elemente de teorie referitoare la tehnologiile Java cu care am lucrat la elaborarea aplicației. Tot în cadrul acestui capitol am prezentat și programele folosite pentru dezvoltarea aplicației.
[anonimizat];
În capitolul al treilea este prezentată aplicația și modul de utilizare al acesteia cu ajutorul imaginilor care vor prezenta elementele interfeței grafice cu utilizatorul ale aplicației.
Capitolul 1 – Tehnologii folosite
1.1 Baze de date
1.1.1 Conceptul de bază de date
Baza de date reprezintă o [anonimizat] o descriere a structurii și a relațiilor dintre date.
Arhitectura bazelor de date evidențiază următoarele componente:
[anonimizat];
Sistemul de gestiune a [anonimizat] a datelor;
[anonimizat], [anonimizat];.
Mijloace hardware (comune ori specializate);
Reglementari administrative destinate bunei funcționări a sistemului;
Personal implicat ([anonimizat], programatori, operatori).
1.1.2 Niveluri de reprezentare a datelor în bazele de date
Pentru a asigura independența fizică și logică a datelor se impune adoptarea unei arhitecturi organizată pe cel puțin trei niveluri de abstractizare[1]:
[anonimizat], [anonimizat] (subscheme). Practic acest nivel reprezintă modul în care utilizatorii percep datele și include o serie de scheme externe sau vederi ale utilizatorilor. La acest nivel fiecare utilizator sau grup de utilizatori au o descriere asupra datelor pe care le manipulează și reprezintă viziunea pe care utilizatorul sau grupul de utilizatori o au asupra bazei de date. Cu alte cuvinte, acest nivel reprezintă acea parte a bazei de date care prezintă interes pentru fiecare dintre utilizatori. Așadar, o bază de date poate avea mai multe scheme externe (vederi), dar numai o singură schemă internă și conceptuală.
Nivelul intern, aferent programatorului, care realizează reprezentarea datelor pe suportul fizic. Acest nivel deține o schemă internă ce descrie structura fizică de stocare a bazei de date. Tot în cadrul acestui nivel se descriu complet atât detaliile stocării, cât și modul de acces la date.
Nivelul conceptual se materializează în schema conceptuală care descrie structura bazei de date, ce oferă o vedere generală asupra bazei de date, prezentând ansamblul datelor ce sunt stocate în baza de date precum și relațiile dintre acestea. Schema conceptuală nu oferă detalii despre modul de memorare a datelor, ci se concentrează pe descrierea entităților, a tipurilor de date, a relațiilor, a operațiilor și a constrângerilor asupra datelor.
Obiectivul arhitecturii pe trei nivele (mai este cunoscută ca arhitectura ANSI / SPARK) este separarea perspectivei pe care o are fiecare utilizator asupra bazei de date și modul în care este reprezentată fizic.
Pentru a determina structura unei baze de date se poate proceda atât ascendent, adică prima dată se procedează la descrierea schemelor externe și apoi se trece la realizarea schemei conceptuale, cât și descendent, pornind de la definirea schemei conceptuale, schemele externe deducându-se ulterior din aceasta.
Figura 1.1 Arhitectura ANSI/SPARK
1.1.3 Modele de baze de date
În funcție de modul de organizare a informațiilor, se evidențiază câteva modele de baze de date: ierarhic(arborescent), rețea, relațional, distribuit, orientat spre obiecte.
Cu ajutorul modelului ierarhic schema bazei de date se reprezintă sub forma unui arbore în care nodurile reprezintă colecții de date, iar ramurile reflectă relațiile de asociere dintre înregistrările colecțiilor de date superioare și cele inferioare. Accesul la înregistrările colecțiilor de date inferioare se face prin traversarea arborelui.
Modelul rețea seamănă cu cel ierarhic, diferența constând în faptul că unui element inferior îi pot corespunde unul sau mai multe elemente superioare.
Modelul relațional este în prezent cel mai răspândit model de bază de date. O bază de date relațională este un ansamblu de relații (tabele) grupate în jurul unui subiect bine definit. Modelul distribuit este rezultatul îmbinării tehnologiei bazelor de date cu cea a rețelelor de calculatoare. Sunt baze de date logic integrate, dar fizic distribuite pe mai multe sisteme de calcul.
Modelul orientat spre obiecte se bazează pe reprezentarea semnificației datelor. Structura de bază folosită pentru reprezentarea datelor este cea de clasă de obiecte definită prin abstractizare din entitatea fizică pe care o regăsim în lumea reală. Acest tip de bază de date a apărut din necesitatea gestionării obiectelor complexe (texte, grafice, hărți) sau a obiectelor dinamice (programe, simulări).
1.1.4 Sistemul de gestiune al bazelor de date (SGBD)
Putem defini un sistem de gestiune al bazelor de date sau SGBD (engl. DBMS – Database Management System) ca o interfață între baza de date și utilizatori, care permite crearea, actualizarea și consultarea bazei de date. Cu alte cuvinte, un SGBD este un ansamblu software de nivel înalt, interpus între utilizatori și baza de date, care permite proiectarea, construirea și administrarea bazelor de date.
Ținând cont de multitudinea sarcinilor ce îi revin unui sistem de gestiune al bazelor de date se pot deduce următoarele funcții:
Organizarea datelor și a legăturilor aferente acestora pentru găsirea cât mai eficientă a lor prin intermediul sistemului de acces – SGBD intern.
Stocarea datelor prin intermediul sistemului de gestiune al fișierelor.
Introducerea și extragerea datelor în formatul cerut de utilizator folosind SGBD-ul extern.
Figura 1.1 Schema generală a unui SGBD
În cadrul unui SGBD se pot identifica mai multe tipuri de limbaje[2]:
Limbajul DDL (engl. Data Definition Language), utilizat in SGBD-urile unde nu există o separație strictă între nivelul conceptual și cel intern, pentru proiectarea și administrarea bazei de date, atât în definirea schemei interne cât și a celei conceptuale.
Limbajul SDL (engl. Storage Definition Language), folosit în cazul în care SGBD-ul are o delimitare clară între nivelul intern și cel conceptual, pentru specificarea schemei interne, iar pentru comenzile la nivel conceptual se folosește limbajul DDL.
Limbajul VDL (engl. View Definition Language) este destinat utilizatorilor pentru definirea schemelor externe și constituie o interfață între utilizatori și nivelul conceptual.
Limbajul DML (engl. Data Manipulation Language) este folosit pentru operațiile tipice privind căutarea, inserarea, ștergerea și modificarea datelor.
1.1.5 Modelul conceptual al bazelor de date relaționale
Apariția modelului relațional s-a produs în iunie 1970, odată cu publicarea de către Edgar Frank Codd în revista Communications of The ACM a articolului „A Relational Model of Data for Large Shared Databanks". În acest articol, autorul aplica o serie de concepte din algebra relațională pentru a rezolva problemele legate de stocarea volumelor mari de date.
Modelul relațional este construit în jurul unei structuri simple și are la bază conceptul matematic de relație definit în teoria mulțimilor, ca fiind produsul cartezian al mai multor mulțimi: … . Familia de mulțimi pe care este definită relația se numește domeniu, numărul n reprezintă gradul relației, un element al relației este numit tuplu, iar numărul de tupluri indică cardinalul relației. Prelucrarea relațiilor se face folosind algebra relațională pe tuplu sau pe domeniu. Eleganța dar și puterea acestui model sunt date de faptul ca relațiile dintre entități se materializează în asocieri care se pot reprezenta sub forma de tabele.
Caracteristicile esențiale ale acestui model sunt:
Orice entitate se reprezintă cu ajutorul unei tabele, numele entității fiind numele tabelei;
Fiecărui atribut al unei entități ii corespunde o coloana în tabela corespunzătoare entității, numele atributului fiind numele coloanei ce ii corespunde în tabelă;
Orice instanță a unei entități se reprezintă printr-un rând în tabela ce reprezintă o entitate, numită înregistrare.
La baza modelului relațional al bazelor de date stă metodologia Entitate-Relație. Modelul Entitate-Relație abstractizează lumea reală și o transpune în agregări de date elementare, numite entități și prin legături între aceste entități, denumite corespondențe sau relații.
O entitate poate fi un obiect din lumea reală (o persoană, o mașină) sau abstractă (un job, o companie, un eveniment). Fiecare entitate are un nume și o serie de proprietăți sau atribute, care descriu entitatea respectivă.
Prin instanța a unei entități se înțelege un singur element, unic, în mulțimea de elemente care formează entitatea respectivă.
Un atribut se definește ca fiind o proprietate a unei entități, caracterizată de un nume și poate lua valori dintr-o mulțime fixată de valori, numită domeniul de valori ale atributului.
Relațiile pot fi definite ca o legătură logică între două sau mai multe entități. Atributele prin care se stabilește relația se numesc chei sau câmpuri de legătură. Relațiile pot fi caracterizate prin grad, adică numărul de entități care participă la relație și prin cardinalitate, adică prin numărul de instanțe ale celor două entități care sunt asociate în relația respectivă.
1.1.6 Proiectarea unei bazei de date
Proiectarea unei baze de date presupune realizarea modelelor conceptual, logic și fizic, prin trecerea de la modelul conceptual al datelor (MCD), la modelul logic al datelor (MLD), apoi de la modelul logic al datelor, la modelul fizic al datelor (MFD). Aceste scheme facilitează comunicarea dintre proiectanții bazei de date, programatori și beneficiari. Stabilirea modelului conceptual pornește de la analiza naturii și a modului în care dorim sa utilizăm datele, ulterior trecându-se la stabilirea regulilor de gestiune și al dicționarului de date.
Trecerea de la MCD la MLD se face ținând cont de următoarele restricții:
Restricții de integritate funcționala (RIF), în care se concretizează cardinalitățile 1,1 (cardinalitate maximă egală cu 1), unde asocierile sunt denumite ierarhice;
Restricții de integritate multipla (RIM), pentru cardinalității cu valori maxime egale cu n și asocierile se numesc non-ierarhice.
Modelul logic al datelor se obține aplicând un set de reguli de trecere de la MCD la MLD[1] și anume:
O entitate devine o relație cu un nume distinct, al cărei identificator devine cheie primară, iar atributele entității vor defini structura relației.
O restricție de integritate funcțională (asociere ierarhica) devine o legătură între relații, adică relația ce provine din entitatea pentru care cardinalitățile sunt 1,1 „absoarbe” identificatorul celeilalte entități care se transformă în cheie externă.
O restricție de integritate multiplă devine o relație a cărei cheie primară este constituită prin concatenarea identificatorilor entităților participante la relație.
Modelul fizic al datelor este obținut prin implementarea modelului logic al datelor într-un SGBD, folosind facilitățile și instrumentele oferite de către acesta.
1.2 Descrierea tehnologiilor folosite
1.2.1 Limbajul de programare Java
Limbajul de programare Java a fost lansat în anul 1995 de către firma Sun Microsystems. Dezvoltarea limbajului a început în anul 1991 odată cu finanțarea de către Sun Microsystems a unui proiect cu numele Green condus de James Gosling. Limbajul a avut un impact puternic în lumea programării și a influențat și alte limbaje de programare precum C#. De-a lungul timpului limbajul a primit numeroase îmbunătățiri și funcționalități, devenind unul dintre cele mai populare limbaje de programare orientate obiect.
Câteva caracteristici ale limbajului[5] sunt:
Limbaj compilat și interpretat;
Limbaj orientat obiect, punând în evidență toate aspectele referitoare la programarea orientată obiect: clase, obiecte, încapsulare, moștenire, modificatori de acces.
Limbaj independent de platformă, aplicațiile fiind compilate și rulate de către mașina virtuala Java (engl. Java Virtual Machine – JVM);
Limbaj concurent, adică are capacitatea de a executa secvențe de cod pe mai multe fire de execuție în același timp;
Limbaj simplu, deoarece, spre deosebire de C++, nu mai avem pointeri și moștenire multiplă, iar alocarea și eliberarea memoriei se face printr-un mecanism automat (engl. garbage collector);
Limbaj distribuit, permițând utilizarea obiectelor atât local cât și la distanță.
Limbaj performant, interpretorul Java fiind capabil să execute byte code aproape la fel de repede ca cel compilat;
Limbaj sigur, deoarece programele Java nu pot accesa porțiuni protejate de memorie (memoria stack și memoria heap), nu folosește pointeri și alocă memorie doar la execuție.
Programele Java nu se execută direct de către procesor, ci sunt translatate într-un limbaj numit byte code ce conține instrucțiuni pentru JVM, care este inspectat de către interpretorul Java și apoi este executat. Interpunerea mașinii virtuale Java între translatarea codului sursă și instrucțiunile mașinii fizice cauzează o scădere a vitezei de execuție. Aceasta performanță redusă era mai evidentă în primele versiuni ale limbajului (era de 10 ori mai lent decât un program scris în cod nativ), dar ulterior performantele au crescut (actualmente este de 2 ori mai lent decât un program scris în cod nativ).
Java dispune și de o colecție impresionantă de biblioteci (engl. Java Frameworks), ce oferă facilitați precum: realizarea interfețelor grafice, programarea rețelelor, programare concurentă, accesarea bazelor de date.
1.2.2 JDBC
Java Database Connectivity (JDBC) este API–ul (engl. Application Programming Interface) dezvoltat de către Sun Microsystems, pentru a oferi programelor Java posibilitatea de a accesa bazele de date gestionate de diverse SGBD-uri. Prin intermediul JDBC, aplicațiile Java pot executa instrucțiuni în limbajul SQL și procesa eventualele rezultate obținute în urma interogărilor. Putem considera JDBC o interfață între o aplicație Java și un SGBD. Programatorii pot crea aplicații, într-un mod uniform și independent de SGBD, deoarece instrucțiunile sunt translatate și transmise mai departe de driverele corespunzătoare fiecărui SGBD. Legătura între drivere, JDBC și un SGBD se poate observa în schema din figura următoare:
Figura 1.2 Arhitectura conectării aplicației Java folosind JDBC
Driverele JDBC sunt specifice fiecărui tip de SGBD și sunt oferite, în mod normal, de către proprietarii de SGBD-ului. Interfețele și clasele cheie necesare pentru dezvoltarea unei aplicații Java care sa utilizeze baze de date sunt: Driver, Connection, Statement (alături de PreparedStatement și CallableStatement) și ResultSet. API-ul JDBC definește aceste interfețe, iar dezvoltatorii driverelor JDBC furnizează implementarea acestor interfețe.
Funcționalitatea acestor interfețe/clase constă în următoarele aspecte:
Driver – încarcă driverul corespunzător;
Connection – realizează conexiunea cu baza de date;
Statement – creează și execută instrucțiuni SQL;
ResultSet – procesează rezultatele obținute în urma executării instrucțiunii SQL.
Pentru ca o aplicație Java sa acceseze și sa obțină informații dintr-o bază de date este nevoie de parcurgea următorilor pași:
Încărcarea driverului JDBC;
Stabilirea unei conexiuni cu baza de date;
Crearea instrucțiunilor SQL;
Executarea instrucțiunilor SQL;
Procesarea rezultatelor obținute.
Încărcarea dinamică a driverului JDBC se face prin metoda statică Class.forName(), având ca și argument un șir de caractere ce reprezintă clasa driver. Driverul este o clasă concretă ce implementează interfața java.sql.Driver. În cazul unor drivere este necesară importarea pachetului ce conține driverul în mediul de dezvoltare. De exemplu, pentru a încărca driverul MySQL Connector/J, care permite conectarea la serverul de baze de date MySQL, este necesar să includem pachetul mysql-connector-java-5.1.26.jar în mediul de dezvoltare. Odată ce driverul s-a încărcat putem stabili o conexiune cu baza de date cu metoda statică getConnection() din clasa DriverManager, ce primește ca argumente un șir de caractere de forma jdbc:<subprotocol>:<nume>. De exemplu, pentru driverele MySQL, sintaxa este jdbc:mysql://server[:port]/numeBazaDate. Dacă baza de date necesită autentificare la semnătura metodei se mai adaugă alte două argumente reprezentând numele de utilizator și parola. Metoda getConnection() are ca rezultat crearea unui obiect Connection, care reprezintă conexiunea la baza de date. După ce am stabilit conexiunea cu baza de date se pot crea și trimite către baza de date instrucțiuni SQL. Crearea instrucțiunilor se face cu ajutorul metodei createStatement(), aplicată unui obiect Connection. Execuția instrucțiunilor folosind una dintre metodele executeQuery(), executeUpdate() sau execute() aferente unui obiect Statement. Dacă se dorește realizarea de apeluri SQL având datele de intrare variabile se folosește clasa PreparedStatement, care este derivată din Statement. Parcurgerea rezultatelor obținute se face cu metoda next(), aferentă unui obiect ResultSet. Închiderea unei conexiuni cu baza de date se face cu metoda close() aplicată obiectului Connection.
1.2.3 JavaFX
Când a fost introdus limbajul de programare Java, interfața grafică se realiza folosind clasele din pachetul Abstract Windows Toolkit (AWT), care permitea crearea de interfețe simple. Nevoia de a crea interfețe moderne și mai complexe a dus la apariția unei noi biblioteci, și anume Swing. Actualmente Swing este înlocuit de către o platformă complet nouă – JavaFX.
Inițial JavaFX a fost bazată pe un limbaj de scripting numit JavaFX Script, care a fost abandonat ulterior. Începând cu versiunea 2.0, JavaFX a fost dezvoltată în limbajul Java și a fost structurată unitar ca și API (engl. Application Programming Interface). Actualmente API–ul JavaFX a ajuns la versiunea 8 și este integrat în distribuția limbajului Java.
Platforma JavaFX încorporează tehnologii moderne pentru crearea de aplicații cu interfețe grafice moderne. Printre facilitățile oferite de JavaFX se numără: suport multi-touch pentru dezvoltarea de aplicații pentru dispozitive mobile, suport pentru animații, suport pentru grafica 2D și 3D, cât și suport multimedia.
JavaFX permite crearea de aplicații, în mod programatic, folosind sintaxa tradițională Java împreună cu API-ul JavaFX, sau declarativ, folosind fișiere FXML. FXML este un limbaj bazat pe XML. Fișierele FXML permit crearea de layout-uri statice (formulare, controale, sau tabele) sau dinamice, prin includerea unor scripturi.
Flexibilitatea API-ului JavaFX permite implementarea celor trei faimoase design pattern-uri folosite în crearea de interfețe grafice: MVC (engl. Model – View – Controller), MVP (engl. Model – View – Presenter), MVVM (engl. Model – View – ViewModel).
Figura 1.3 Arhitectura JavaFX, sursa https://docs.oracle.com
JavaFX are o arhitectură bazată pe o stivă de componente după cum se poate observa în figura 1.3. Nivelul superior al arhitecturii este JavaFX Public APIs, ce cuprinde un set complet de API-uri Java pentru dezvoltarea de aplicații ce implică interacțiunea cu utilizatorul. Graful scenei (engl. Scene Graph) sau arborele de elemente grafice cuprinde o ierarhie de elemente (noduri) ce reprezintă elementele vizuale ale interfeței grafice cu utilizatorul. Fiecare nod din graful de scene este identificat unic și are un părinte, cu excepția nodului rădăcină, dar și unul sau mai multe noduri copil. Arhitectura JavaFX mai cuprinde Quantum Toolkit, ce reprezintă motorul pe care rulează codul propriu zis, un motor grafic performant – Prism, un sistem eficient de ferestre de mici dimensiuni – Glass, motorul pentru redare conținutului multimedia – Media Engine, un motor pentru integrarea conținutului internet – Web Engine.
O interfață grafică cu utilizatorul JavaFX se exprimă prin clase de următoarele tipuri (figura 1.4):
javafx.stage.Stage – care reprezintă fereastra principală;
javafx.scene.Scene – care are asociat graful de noduri și menține o organizare internă a elementelor grafice din cadrul aplicației;
javafx.scene.Node – ce reprezintă elementele din cadrul arborelui de elemente grafice, care pot fi figuri geometrice, text, imagini sau controale UI.
Figura 1.4 Elementele interfeței cu utilizatorul ale unei aplicații JavaFX
Orice aplicație JavaFX trebuie sa aibă o clasă derivată din clasa Application de la care moștenește cele trei metode ce definesc ciclul de viață al aplicației:
Metoda init(), care este apelată în momentul când aplicația își începe execuția;
Metoda start(), apelată după init(), are menirea de a construi un obiect Scene, de a plasa în cadrul grafului de scene nodurile și de a-l afișa în cadrul Stage-ului;
Metoda stop(), care se apelează când aplicația își termina execuția.
Lansarea în execuție a unei aplicații JavaFX se face prin apelarea metodei launch().
1.2.4 Design pattern-ul MVC (Model – View – Controller)
MVC este filozofia clasică pentru proiectarea interfețelor grafice în limbajele obiectuale folosită încă din anii 1970. Modelul arhitectural reprezintă structurarea aplicației pe trei componente[5]:
Model – componenta ce păstrează, în general, datele cărora se dorește să li se dea o vizualizare, numindu-se în acest caz model de date. Modelele comunică indirect cu vizualizarea (engl. view) și cu controlerul (engl. controller) prin intermediul sistemului de evenimente. În cazul aplicațiilor cu baze de date, modelul asigură comunicarea cu baza de date și realizează operațiuni asupra datelor din baza de date.
Vizualizare (engl. view) – constituie reprezentarea vizuală a modelului. Această componentă este responsabilă pentru păstrarea pe ecran a reprezentării actualizate, primind în acest sens mesaje de la model și controler.
Controler (engl. controller) – preia datele de intrare introduse de utilizatori în vizualizare și le transformă în schimbări corespunzătoare în model. Controlerul are rolul de determina modul în care va răspunde componenta la evenimentele provenite dinspre dispozitivele de intrare.
Figura 1.5 Interacțiunea componentelor MVC
Fiecare dintre aceste componente are propria funcționalitate și interacționează cu celelalte parți după cum se poate observa în figura 1.5.
Avantajele folosirii arhitecturii MVC constă în obținerea unei aplicații modulare, mai ușor de dezvoltat, de depanat și de adăugat noi funcționalități.
1.2.6 Mediul de dezvoltare IntelliJ IDEA
IntelliJ IDEA Community Edition (versiunea gratuită) este un mediu de dezvoltare pentru limbajul Java, modern, popular, fiind folosit la scară largă în industria programării în limbajul Java de nume sonore precum Google.
Figura 1.6 Mediul de dezvoltare Intellij IDEA
Interfața este organizată în mai multe ferestre sau view-uri care afișează entități sau analize ale codului sursă. Cele mai importante elemente ale interfeței sunt: fereastra Editor, fereastra Proiect, fereastra Structure și fereastra Run. Fereastra Editor afișează codul sursa al elementului selectat din cadrul proiectului, afișând sub forma de tab-uri istoricul entităților accesate. Fereastra Proiect arată structura proiectului curent și oferă posibilitatea de a vizualiza proiectul ca structură de fișiere sau pachete. Fereastra Structure arată conținutul unui element activ afișând metodele, atributele și clase interioare ale acestuia facilitând navigarea prin structura elementului. Fereastra Run afișează mesaje din timpul execuției programului.
Interfața prietenoasă și facilitățile oferite au făcut ca acest mediu de dezvoltare sa fie situat în topul preferințelor programatorilor Java.
1.2.7 JavaFX Scene Builder
Există două abordări pentru a crea interfețe grafice cu utilizatorul în JavaFX, programatic și declarativ. Abordarea declarativă are în centrul său fișierele FXML, care au menirea să stocheze informații referitoare la elementele interfeței aplicației. Fișierele FXML pot fi editate în mediul de dezvoltare Java preferat, dar există și o unealtă vizuală capabilă să manipuleze fișierele FXML numită JavaFX SceneBuilder. Utilitarul JavaFX SceneBuilder este un instrument dezvoltat de compania Oracle pentru crearea rapidă a interfețelor grafice în JavaFX. Programul generează automat un fișier în format FXML care poate fi atașat, în cadrul unui proiect Java, de logica unei aplicații.
Figura 1.7 Aplicația JavaFX SceneBuilder
Aplicația JavaFX SceneBuilder 1.0 a fost lansată în anul 2012, iar în anul 2014 a fost actualizată la versiunea 2.0, versiune ce este capabilă să lucreze cu JavaFX 8. Versiuni mai noi ale aplicației nu mai sunt oferite de Oracle în format binar, ci doar în formatul fișiere sursă. Totuși, versiuni mai noi ale aplicației pot fi descărcare de pe site-ul http://gluonhq.com/open-source/scene-builder/, care oferă versiuni actualizate ale aplicației în format compilat, compatibile cu toate platformele majore. JavaFX SceneBuilder este o unealtă vizuală completă, ce asigură productivitate sporită în crearea ferestrelor interfețelor grafice, punând la dispoziție o varietate de elemente vizuale ce pot fi manipulate în mod direct. Majoritatea IDE-urilor Java au integrat în meniu aplicația, dar nu conțin efectiv aplicația, fiind necesară instalarea separată a acesteia și specificarea ulterioară în mediul de dezvoltare a căii către executabilul aplicației.
Interfața aplicației este împărțită în mai multe view-uri sau panouri cum se poate observa în figura 1.7. În partea stânga avem panoul Library, ce conține, în principal, următoarele elemente: containers – elemente de tip container (engl. Pane), elemente de tip control (butoane, checkbox-uri, butoane radio etc.), elemente specifice pentru crearea meniurilor, figuri geometrice, reprezentări grafice. Tot în partea stângă avem panoul Document ce conține: Hierarchy în care este reprezentată ierarhia elementelor aflate pe suprafața de lucru și Controller, unde se introduce calea spre clasa controler responsabilă cu logica interfeței. Această acțiune este necesară deoarece fișierele FXML conțin informații referitoare doar la elementele interfeței, nu și la modul în care vor funcționa, partea funcționalității fiind data de clasa controler. În partea dreaptă avem panoul Inspector ce conține următoarele secțiuni: Properties – afișează caracteristicile unui element selectat din suprafața de lucru, care se poate modifica prin introducerea valorilor, Layout – permite modificarea proprietăților referitoare la layout-ul unui element al interfeței grafice și Code – secțiunea responsabilă cu logica din spatele elementelor (nodurilor), ce asigură identificarea elementelor interfeței (fx:id-ul), precum și specificarea metodelor din clasa controler responsabile cu gestionarea unui anumit tip de eveniment.
1.2.8 TIBCO Jaspersoft Studio
TIBCO Jaspersoft Studio[7] este un program gratuit, bazat pe mediul de dezvoltare Java Eclipse, care permite crearea de rapoarte cu un format complex, cu accesarea bazei de date prin intermediul JDBC, JavaBeans, XML și oferă posibilitatea afișării rapoartelor create în format PDF, HTML, XHTML, RTF, XML. Programul este cel mai populară unealtă pentru crearea de rapoarte pentru aplicații Java. Jaspersoft Studio alături de JasperReports Library (biblioteci de clase) au apărut din necesitatea de a putea adaugă unei aplicații Java funcționalitatea de a afișa sau lista rapoarte, implicând o cantitate minimă de cod.
Ciclul de viață al unui raport Jasper cuprinde trei etape distincte (figura 1.8):
Etapa de design consta în crearea fișierului JRXML, care este un document XML, ce conține informații despre layout-ul raportului. Acest fișier poate fi creat manual într-un editor de text sau se poate crea, în mod vizual, folosind Jaspersoft Studio;
Etapa de execuție constă în contopirea dintre un fișier JRXML și o sursă de date, care poate sa fie o interogare SQL, un fișier XML, un fișier CVS, o interogare HQL (Hibernate Query Language), având ca rezultat popularea cu date a fișierului JRXML. Înaintea execuției raportului, fișierul JRXML este compilat într-un obiect binar numit fișier Jasper (extensia .jasper). Compilarea este necesară din rațiuni de performanță. Clasa net.sf.jasperreports.engine.JasperFillManager din biblioteca JasperReports, oferă funcțiile necesare pentru introducerea datelor într-un raport Jasper este și are ca rezultat obținerea unui fișier pentru listare Jasper (extensie .jrprint);
Etapa de exportare constă în folosirea fișierului pentru listare Jasper care prin folosirea clase JasperExportManager permite exportarea lui în diferite formate (pdf, doc, ppt, xls, cvs).
Figura 1.8 Ciclul de viată al unui raport Jasper
Figura 1.9 Interfața programului TIBCO Jaspersoft Studio
Interfața grafică a programului este împărțită în mai multe ferestre sau view-uri după cum se poate observa în figura 1.9. Cele mai folosite view-uri sunt:
Repository Explorer, prezintă lista conexiunilor serverului Jasper, dar și conexiunile cu sursele de date;
Outline, arată structura completă a raportului;
Properties, ce oferă accesul la caracteristicile unui obiect selectat, în scopul editării sau vizualizării;
Editor reprezintă zona de lucru în care se lucrează în cadrul procesului de design al raportului;
Palette conține elementele necesare realizării unui raport.
Problems afișează lista cu probleme sau erori ce pot să apară pe parcursul procesului de design și de compilare a raportului.
Raportul Jasper creat poate fi vizualizat atât în modul design, cod sursă sau previzualizat prin selectarea tab-urilor Design, Source și Preview, aflate în josul ferestrei Editor.
1.2.9 MySQL și utilitarul MySQL Workbench
Sistemul de baze de date MySQL a fost dezvoltat de către compania MySQL AB, care a fost preluată în anul 2008 de către Sun Microsystems.
Popularitatea MySQL consta în următoarele aspecte[6]:
Viteza – în conformitate cu părerile programatorilor, MySQL este unul dintre cele mai rapide sisteme de baze de date la ora actuală;
Ușurința în utilizare – configurarea și administrarea este mai facila datorită simplității sale;
Suport SQL – oferă suport nativ pentru limbajul SQL;
Capabilități multi-threading – oferă posibilitatea conectării simultane a utilizatorilor care pot folosi multiple baze de date în mod concurent;
Portabilitate – sistemul rulează pe majoritatea platformelor Unix, Linux, Windows, de la servere la dispozitive mobile;
Dimensiuni reduse – distribuția are dimensiuni reduse în comparație cu alte sisteme;
Costul – MySQL se află sub licența GPL (engl. GNU General Public License), ceea ce înseamnă ca este gratuit pentru majoritatea utilizărilor interne.
Figura 1.10 Utilitarul MySQL Workbench
MySQL Workbench este un mediu vizual, unificat, pentru sistemul de baze de date MySQL destinat arhitecților, programatorilor și administratorilor de baze de date, care oferă, în principal, următoarele funcționalități[8]:
Designul vizual al bazelor de date MySQL, incluzând instrumentele necesare pentru crearea vizuală de modele entitate-relație(ER) complexe, transformarea acestor modele în baze de date fizice și viceversa;
Modificarea tuturor aspectelor referitoare la baza de date;
Programarea în limbajul SQL, oferind posibilitatea de a crea și de a executa interogări SQL prin intermediul editorului SQL integrat;
Administrarea serverelor MySQL, oferind o varietate de instrumente pentru configurarea serverelor, a utilizatorilor, backup-ul, recuperarea precum și auditul bazelor de date;
Vizualizarea performanțelor, având instrumente pentru optimizarea performanțelor aplicațiilor MySQL;
Migrarea bazelor de date, punând la dispoziție o soluție foarte ușor de utilizat pentru migrarea bazelor de date spre alte formate (Microsoft SQL Server, Microsoft Access, Sybase ASE, PostgreSQL etc.).
Capitolul 2 – Proiectarea și dezvoltarea aplicației
Aplicația are drept scop gestionarea rezervărilor/închirierilor din cadrul unui hotel sau unei alte structuri de cazare și este realizată folosind limbajul de programare Java împreună cu sistemul de baze de date MySQL, fiind un exemplu de design al bazelor de date relaționale precum de programare în limbajul Java.
Pentru dezvoltarea aplicației s-au folosit o varietate mare de programe profesionale și anume: administratorul de baze de date MySQL – MySQL Workbench Community Edition, serverul MySQL Community Server, instrumentul pentru crearea rapoartelor TIBCO Jaspersoft Studio, utilitarul pentru crearea de layout-uri în JavaFX – JavaFX SceneBuilder și mediul de dezvoltare Java Intellij IDEA Community Edition.
2.1 Proiectarea bazei de date
Așa cum am prezentat în capitolul anterior, proiectarea unei baze de date presupune realizarea modelelor conceptual, logic, fizic, prin trecerea de la MCD la MLD și de la MLD la MFD. Modelul de date de nivel înalt cel mai frecvent folosit pentru reprezentarea datelor la nivel conceptual este modelul entitate-relație, iar cea mai larg utilizată reprezentare grafică a acestuia este diagrama entitate-relație, numită și harta relațiilor, sau ERD (engl. Entity-Relationship-Diagram).
2.1.1 Modelul conceptual al datelor (MCD)
Realizarea modelului conceptual pornește de la analiza naturii și a modului în care dorim să utilizam datele.
Regulile de ghidare pentru modelul conceptual al bazei de date:
În cadrul hotelului pot lucra mai mulți angajați ce vor fi grupați în două categorii: administratorii cu drepturi depline asupra bazei de date și utilizatorii normali care vor avea privilegii restrânse;
Hotelul va avea un anumit număr de camere care vor putea fi rezervate sau închiriate;
Un hotel poate avea unul sau mai mulți clienți, care vor putea să rezerve sau să închirieze una sau mai multe camere;
Un angajat poate efectua una sau mai multe rezervări;
Fiecare rezervare sau închiriere poate genera una sau mai multe facturi.
O rezervare va conține o singură cameră;
Atât clienții cât și angajații sunt persoane fizice;
Deoarece atât clienții, cât și angajații sunt persoane, care au atribute comune, se va crea o entitate care va avea atributele comune atât pentru clienți cât și pentru angajați. S-a procedat în acest sens pentru a evita o eroare de proiectare a bazelor de date relaționale numită redundanță[4].
Din analizarea cerințelor de mai sus rezultă următoarele entități:
PERSOANE – entitate părinte folosită pentru a gestiona atât clienții cât și angajații structurii de cazare. Identificarea fiecărei persoane se face prin proprietatea idpersoana care este un identificator unic deoarece presupunem că nu există două persoane cu același cod. Entitatea mai conține atributele: nume, prenume pentru numele și prenumele unei persoane, tip_document și seria_document pentru a specifica tipul documentului de identitate (CI, BI, pașaport etc.) și seria documentului de identitate, adresa, telefon și email pentru a identifica adresa, numărul de telefon respectiv e-mail-ul persoanei.
CLIENȚI – entitate copil folosită pentru a gestiona clienții care solicită efectuarea de rezervări sau închirieri, având atributul cod_client.
ANGAJAȚI, entitate copil folosită pentru a gestiona angajații și are o serie de atribute: salariul (specifică salariul angajatului), acces (specifică drepturile de acces în sistem), username (numele de utilizator cu care angajatul intră în aplicație), password (parola cu care angajatul intră în aplicație), situație_angajat (reprezintă situația angajatului în cadrul sistemului);
REZERVĂRI, entitate folosită pentru a gestiona rezervările, și are ca atribute: idrezervare (identificator unic), tip_rezervare (specifică tipul operațiunii care se va efectua), data_rezervare (data la care a fost făcută rezervarea), data_check_in, data_check_out, total_nopți (numărul total al nopților de cazare), situație_rezervare (situația rezervării sau a închirierii);
CAMERE, entitate folosită pentru gestionarea camerelor și conține următoarele atribute: idcamera (identificator unic), numar (numărul camerei), tip_camera (tipul camerei), descriere (descrierea facilităților camerei), caracteristici (caracteristicile camerei), tarif (tariful pe noapte al camerei), situație_cameră (situația în care se află camera);
FACTURI, entitate folosită pentru gestiunea facturilor, având ca identificator unic atribuitul idfactura, data (data la care a fost realizată factura), tva (cota tva aplicată), total (totalul facturii fără tva), total_tva (totalul tva-ului), total_cu_tva (total facturii după aplicarea tva), situație_factură (situația în care se află factura).
Următorul pas în definirea modelului conceptual este stabilirea corespondențelor (relațiilor) între entități. Prin urmare se identifică următoarele relații între entitățile date:
Între entitatea PERSOANE și entitățile CLIENȚI și ANJGAJAȚI sunt relații de tip unu-la-unu, ierarhice, entitatea PERSOANE fiind entitatea părinte, deoarece reunește atributele comune atât ale angajaților, cât și pe cele ale clienților (sunt persoane), iar ANGAJAȚI și CLIENȚI sunt entități copil.
Între entitățile CLIENȚI – REZERVĂRI este o relație tip unu-la-mai-mulți: un client poate solicita efectuarea de la 1 la n rezervări, de unde rezultă corespondența SOLICITĂ.
Între entitățile ANGAJATI – REZERVARI este o relație tip unu-la-mai-mulți: un angajat poate efectua de la 1 la n rezervări, rezultând corespondența EFECTUEAZĂ / ANULEAZĂ.
Între entitățile REZERVĂRI – CAMERE, relație tip unu-la-mai-mulți: o camera poate să apară în de la 1 la n rezervări și rezultă corespondența CONȚINE.
Între entitățile REZERVĂRI – FACTURI, relație tip unu-la-mai-mulți: pe baza unei rezervări se pot emite de la 1 la n facturi, rezultând corespondența CONFORM CU.
La finalul definirii modelului conceptual se stabilesc cardinalitățile corespondentelor definite anterior:
Corespondențele dintre entitatea PERSOANE și entitățile CLIENȚI și ANGAJAȚI vor avea cardinalități (1, 1) în ambele sensuri ale relației;
Corespondența SOLICITĂ are următoarele cardinalități:
Dinspre entitatea CLIENȚI (1, n) – un client face o rezervare (cardinalitate minimă 1) sau mai multe rezervări (cardinalitate maximă n);
Dinspre entitatea REZERVĂRI (1, 1) – o rezervare aparține unui client (cardinalitate minimă 1) și cel mult unui client (cardinalitate maximă 1);
Corespondența EFECTUEAZĂ/ANULEAZĂ are următoarele cardinalități:
Dinspre entitatea ANGAJAȚI (1, n) – un angajat poate efectueze o rezervare (cardinalitate minimă 1) sau mai multe rezervări (cardinalitate maximă n);
Dinspre entitatea REZERVĂRI (1, 1) – o rezervare poate fi făcută de un angajat (cardinalitate minimă 1) și cel mult de un angajat (cardinalitate maximă 1);
Corespondența CONȚINE are următoarele cardinalități:
Dinspre entitatea REZERVĂRI (1, 1) – o rezervare are cel puțin o cameră (cardinalitate minimă 1) și cel mult o cameră (cardinalitate maximă 1);
Dinspre entitatea CAMERE (1, n) – o cameră poate să fie conținută de o rezervare (cardinalitate minimă 1), sau poate să fie conținută de mai multe rezervări (cardinalitate maximă n);
Corespondența CONFORM CU are următoarele cardinalități:
Dinspre entitatea REZERVĂRI (1, n) – o rezervare generează o factură (cardinalitate minimă 1) sau mai multe facturi (cardinalitate maximă n);
Dinspre entitatea FACTURI (1, 1) – o factură este generată de cel puțin și de cel mult de o rezervare (cardinalitate minimă 1, cardinalitate maximă 1);
Figura 2.1 Modelul conceptual al datelor
2.1.2 Modelul logic al datelor (MLD)
Modelul logic al datelor se obține prin aplicarea regulilor de trecere de la MCD la MLD enunțate în capitolul anterior la proiectarea bazelor de date, rezultând următoarele relații:
PERSOANE (idpersoană , nume, prenume, tip_document, seria document, adresa, telefon, email);
CLIENȚI (#idpersoană, cod_client);
ANGAJAȚI ( #idpersoană, salariul, acces, username, password, situație_angajat);
REZERVĂRI (idrezervare, #idcamera, #idclient, #idangajat, tip_rezervare, data_rezervare, data_check_in, data_check_out, total_nopti, situație_rezervare);
CAMERE (idcameră, număr, nivel, tip_cameră, descriere, caracteristici, tarif, situație_cameră);
FACTURI (idfactură, #idrezervare, data, tva, total, total_tva, total_cu_tva, situație_factură).
Se observă că au apărut, în unele entități, chei externe și chei primare ca urmare a aplicării regulilor de trecere de la modelul conceptual al datelor la modelul logic al datelor. Datorită faptului că avem o relație ierarhică între entitățile CLIENȚI și ANGAJAȚI, pe de o parte, și PERSOANE, pe de altă parte, cheia primară idpersoană din entitatea PERSOANE a trecut și a devenit atât cheie primară, cât și cheie externă în entitățile subordonate CLIENȚI și ANGAJAȚI.
Figura 2.2 Modelul logic al datelor
2.1.3 Modelul fizic al datelor (MFD)
Trecerea de la modelul logic al datelor la modelul fizic al datelor se face utilizând facilitățile SGBD-ului ales. Pentru implementarea fizică a bazei de date am ales MySQL, deoarece este gratuit și este, actualmente, unul dintre cele mai populare și mai rapide sisteme gestiune al bazelor de date relaționale. Deoarece SGBD-ul MySQL implementează în totalitate teoria modelului relațional, trecerea de la MLD la MFD se face relativ simplu prin transpunerea relațiilor în tablele, iar legăturile dintre tablele se realizează prin corespondențele dintre cheile primare și cele externe. Pentru implementarea fizică a bazei de date vom folosi software-ul MySQL Workbench, deoarece ne oferă o perspectivă vizuală de a realiza modelul fizic al bazei de date. Introducerea tabelelor în modul vizual se face alegând din bara de instrumente tabelul și se introduce în suprafața de lucru cu un mouse click la poziția dorită în suprafața de lucru. Datele se introduc selectând tabelul și introducând în secțiunea de jos a suprafeței de lucru numele coloanelor tabelului, cu specificarea tipului de date (integer, varchar, date etc.), precum și a altor alte atribute. Pentru exemplificare am reprezentat grafic introducerea tabelului persoane în MySQL Workbench (figura 3.3).
Figura 2.3 Crearea tabelului persoane in MySQL Workbench
Figura 2.4 Reprezentarea schemei bazei de date în MySQL Workbench
După introducerea tabelelor se vor introduce și relațiile (corespondențele) dintre acestea, în conformitate cu modelul logic stabilit mai sus. După introducerea relațiilor și a tabelelor în modelul fizic al bazei cu ajutorul MySQL Workbench baza de date va avea structura ca în figura 2.4. Pentru a crea fizic baza de date MySQL Workbench oferă o funcție numită Forward Engineer care creează, după schemă, baza de date și o instalează pe serverul MySQL. O altă posibilitate este exportarea schemei bazei de date creare în modul vizual sub formă de script care se poate executa în consola, având ca efect crearea efectivă a bazei de date.
2.2 Dezvoltarea aplicației în limbajul Java
Aplicația va fi realizată in limbajul Java, deoarece este un limbaj de programare modern, orientat obiect, ce permite realizarea unei mari varietăți de aplicații. Java oferă de asemenea posibilitatea nativă de a lucra cu baze de date, având implementat în nucleul sau API-ul JDBC (Java Database Connectivity), ce oferă o modalitate facilă de conectare la bazele de date, de a executa comenzi conforme cu standardele SQL și de a performa alte obiective comune bazelor de date. De asemenea, Java oferă instrumentele necesare pentru crearea de interfețe grafice cu utilizatorii (engl. GUI – Graphical User Interface) având la dispoziție posibilitatea de a alege între trei API-uri: AWT(engl. Abstract Windowing Toolkit), Swing sau JavaFX. Datorită faptului că primele două API-uri nu mai primesc îmbunătățiri (tehnologic sunt considerate „moarte”), pentru interfața grafică aplicației am ales API-ul JavaFX datorită faptului că este modern, flexibil și permite crearea de aplicații cu interfețe grafice complexe. Un alt motiv pentru care am ales JavaFX este faptul că poate fi folosit la implementarea pattern design-ul MVC, arhitectura ce va fi folosită în designul aplicației.
JavaFX permite crearea de aplicații, în mod programatic, folosind sintaxa Java împreună cu API-ul JavaFX, sau declarativ, folosind fișiere FXML. Pentru realizarea interfeței grafice utilizator am ales cea din urmă modalitate. Din perspectiva MVC fișierele FXML conțin descrierea interfeței grafice și reprezintă componenta view. Componenta controler în JavaFX este formată din clase Java ce conțin metodele ce descriu acțiunile declanșate de acțiunea utilizatorului asupra elementelor de tip control ale interfeței grafice. Modelul este reprezentat, în cadrul aplicațiilor JavaFX, de clase ce definesc tiparul datelor cu care va lucra și pe care le va afișa aplicația.
2.2.1 Structura aplicației
Pentru structurarea aplicației, clasele ce compun aplicația au fost organizate într-o serie de pachete, având denumiri referitoare la modulele arhitecturii MVC. Așadar aplicația are o serie de pachete care au fost denumite sugestiv cu rolul pe care îl au in cadrul aplicației sau rolul in cadrul arhitecturii MVC, astfel:
Pachetul animații, conține clasele ce realizează efectele de tranziție ale ferestrelor;
Pachetul controler, conține clasele controler asociate fișierelor FXML, reprezentând componenta controler din MVC;
Pachetul formulare, conține clasele ce definesc metodele responsabile cu conectarea la baza de date precum și operațiile cu baza de date și se integrează, din punct de vedere al funcționalității în componenta model din MVC;
Pachetul foto, conține imaginile ce vor fi folosite în cadrul interfeței grafice;
Pachetul main, conține clasa principală a aplicației;
Pachetul model, conține pachetul ce conține clasele de tip model din arhitectura MVC;
Pachetul rapoarte, conține fișierele în format JRXML reprezentând formularele Jasper;
Pachetul stilizare – fișierele de stil în format CSS ce definesc stilul interfeței grafice;
Pachetul view – conține formularele stocate în fișiere FXML și reprezintă componenta view în cadrul MVC.
Figura 2.5 Diagrama pachetului animații
Figura 2.6 Diagrama claselor din pachetului controler
Pachetul animații are în structura sa trei clase și are diagrama conform figurii 2.5 Clasele sunt responsabile cu realizarea tranzițiilor ferestrelor și au denumiri sugestive referitoare la efectul de tranziție pe care îl generează. Clasa CachedTimelineTransition este o clasă derivată din clasa Transition, care la rândul ei, este superclasă pentru alte două clase: FadeInRightTransition, pentru crearea efectului de tranziție fade in spre dreapta al unei ferestre și FadeOutLeftTransition, pentru crearea efectului de tranziție fade out spre stânga al unei ferestre.
Pachetul controler (vezi figura 3.6) conține clasele tip controler, care sunt responsabile cu gestionarea evenimentelor ce apar în cadrul interfeței grafice. Practic, aceste clase conțin logica din spatele formularelor, descriind acțiunile pe care aplicația la va executa pentru gestionarea evenimentelor apărute în urma interacțiunii cu interfața grafică a aplicației. De exemplu, acțiunea asupra unui element al interfeței grafice va declanșa automat execuția unei metode definită în clasa controler atașată formularul respectiv. Toate clasele din pachetul controler reprezintă și componenta cu același nume în arhitectura MVC. De asemenea, toate clasele tip controler în JavaFX pot implementa interfața Initializable, ce are o singură metodă initialize() și care se execută în mod automat atunci când se apelează metoda statică load() a clasei FXMLLoader, având ca argument calea fișierului FXML ce are asociată clasa controler. Metodele de tip event handler (toate cele care au în componența numelui expresia „handle”), prezente în clasele acestui pachet, primesc ca și argumente clasele din pachetul JavaFX.event și se ocupă cu tratarea evenimentelor declanșate de utilizator în interacțiunea cu interfața grafică. În cadrul clasei facturiFormController avem definită o clasă internă ButtonCell, necesară pentru afișarea butoanelor în cadrul unei celule a tabelului cu facturile (va afișa două butoane: unul pentru listare și unul pentru ștergerea facturii).
Deoarece clasele care se încadrează în componenta model în MVC sunt destul de voluminoase și era dificilă reprezentarea diagramei am ales ca această componentă să fie scindată și reprezentată prin intermediul a două pachete:
pachetul formulare (figura 2.6), care conțină clasele care responsabile cu conectarea la baza de date, dar și cu efectuarea de operații cu baza de date;
pachetul model (figura 2.7), care va conține acele clase care definesc modelul de date cu care va lucra aplicația (persoane, clienți angajați, camere etc.).
Figura 2.7 Diagrama claselor din pachetului formulare
Figura 2.8 Diagrama claselor din pachetului model
Dat fiind faptul că aplicația execută un număr mare de operațiuni asupra bazei de date, era necesară pentru evitarea redundanței codului, să se implementeze o clasă responsabilă cu conectarea la baza de date, sarcină care îi revine clasei conectareDB.
După stabilirea conexiunii cu baza de date, programul poate executa comenzi SQL, iar acest lucru este asigurat de către celelalte clase prezente în pachetul formulare, ce conțin metode pentru efectuarea de operații specifice lucrului cu bazele de date: afișare, actualizare, inserare și ștergere (operații CRUD) pentru tabelele existente în baza de date. Pentru executarea de comenzi SQL din cadrul aplicației către baza de date, am folosit interfața Statement care execută comenzi statice SQL. Interfața PreparedStatement este derivată din interfața Statement și oferă posibilitatea de a executa comenzi SQL precompilate, care vor fi folosite cu preponderență în aplicație din rațiuni de performanță. Clasele din pachetul formulare mai conțin metodele getter și setter, pentru returnarea, respectiv modificarea valorilor atributelor claselor.
Ținând cont de faptul că în baza de date avem o relație ierarhică, era necesar ca această relație ierarhică să fie modelată și la nivelul modelului de date. Prin urmare, am creat superclasa persoane și două clase derivate clienți și angajați, care moștenesc atributele clasei persoane, dar conțin și atributele ce le specializează.
Pachetul main (figura 2.9) conține o singură clasă – Main, care constituie punctul de start al aplicației de față și în cadrul căreia avem definite două metode: start și main.
Figura 2.9 Diagrama pachetului Main
La final diagrama completă a aplicației va arata ca în figura 2.10. Pentru simplitate, am redus reprezentarea claselor doar la numele lor.
Figura 2.10 Diagrama completă a claselor aplicației
2.2.2 Exemple de tipare de programare folosite pentru dezvoltarea aplicației
Deoarece scopul aplicației noastre este manipularea datelor persistente dintr-o bază de date, programul nostru trebuie să aibă o conexiune cu baza de date. În Java API-ul ce oferă funcționalitățile necesare lucrului cu bazele de date este JDBC (Java Database Connectivity) Acesta permite crearea de aplicații Java care permit accesarea și manipularea bazelor de date relaționale. În cazul aplicației de față, clasa responsabilă cu conexiunea la baza de date este conectareDB. Codul sursa al clasei responsabile cu realizarea conexiunii cu baza de date este:
public class conectareDB {
public String db = "rezervarihotel";
public String url = "jdbc:mysql://127.0.0.1/" + db;
public String user = "usermane";
public String pass = "password";
public conectareDB() {
}
public Connection connect(){
Connection link = null;
try {
Class.forName("com.mysql.jdbc.Driver");
link = DriverManager.getConnection(this.url, this.user, this.pass);
} catch (ClassNotFoundException | SQLException e) {
Alert alert = new Alert(Alert.AlertType.ERROR,"Eroare conexiune cu baza de date");
alert.initStyle(StageStyle.DECORATED);
alert.setTitle("Eroare!!!");
alert.showAndWait();
}
return link;
}
}
Clasa conectareDB are o singură metodă fără argumente connect, care, în cazul în care nu apar erori, va realiza o conexiune cu baza de date. Pentru conectarea aplicației la baza de date este necesar în primul rând să încărcam driverele corespunzătoare SGBD-ului ales pentru utilizare. Driverele sunt puse la dispoziție de companiile care dezvolta și SGBD-ul și constă într-un pachet de tip executabil Java (în cazul nostru driverul este mysql-connector-java-5.1.38-bin.jar, descărcat de pe site-ul oficial MySQL). Este necesar ca driverul să fie importat în mediul de dezvoltare, în structura proiectului. Datorită faptului că baza de date este realizată în MySQL am încărcat driverul, cu instrucțiunea Class.forName(„com.mysql.jdbc.Driver”). Crearea conexiunii cu baza de date se face prin folosirea metodei statice getConnection() din clasa DriverManager care, în cazul în care nu exista erori, va returna un obiect Connection, ce reprezintă conexiunea cu baza de date. Cele doua instrucțiuni au fost introduse într-un bloc de cod try/catch deoarece pot apărea erori de conexiune cu baza de date (de exemplu, driver incorect sau datele de acces în baza de date incorecte). În cazul în care o eroare clasa va afișa o fereastră, care atenționează asupra eșecului conexiunii.
Odată realizată conexiunea cu baza de date aplicația poate executa operații specifice lucrului cu bazele de date (operații CRUD). Pentru executarea de interogări din cadrul unei aplicații Java asupra unei baze de date se folosește interfața Statement și interfața derivată din ea PreparedStatement, ambele disponibile în API-ul JDBC. Interfața PreparedStatement este foarte eficientă atunci când avem de-a face cu execuții repetate ale unei instrucțiuni SQL.
Pentru exemplificarea modului în care aplicația execută o operație de inserare a unei înregistrări baza de date voi prezenta codul aferent metodei insert ce îndeplinește această operațiune:
public void insert(ModelFactura model){
stmtSQL = "insert into facturi(idrezervare, data, tva, total, total_tva, total_cu_tva, situatie_factura) values (?,?,?,?,?,?,?)";
try(PreparedStatement ps = connection.prepareStatement(stmtSQL)){
ps.setInt(1, model.getIdRezervare());
ps.setDate(2, model.getData());
ps.setInt(3, model.getTva ());
ps.setDouble (4, model.getTotal ());
ps.setDouble (5, model.getValoareTva());
ps.setDouble (6, model.getTotalCuTva ());
ps.setString (7, model.getStatus ());
ps.executeUpdate();
}
catch(Exception ex){
alertWindow (Alert.AlertType.ERROR, ex.toString ());
}
}
Codul de mai sus descrie metoda responsabilă cu introducerea unei facturi în baza de date. În primă fază am definit șirul de caractere stmtSQL ce desemnează instrucțiunea SQL pentru operațiunea de inserare și reprezintă argumentul metodei prepareStatement(), care este aplicată conexiunii cu baza de date connection având ca rezultat crearea unui obiect PreparedStatement. Semnele de întrebare reprezintă înlocuitori pentru parametrii ce reprezintă coloanele tabelului facturi. Acordarea de valori acestor parametri se face cu metodele setX(setInt, setDouble, setDate, set String). Metoda executeUpdate() aplicată obiectului PreparedStatement ps execută instrucțiunea SQL. Deoarece codul poate declanșa excepții de tipul SQLException a fost integrat într-un bloc try/catch. Daca operația eșuează se va afișa o fereastră cu detaliile erorii apărute.
2.2.3 Realizarea interfeței grafice cu utilizatorul folosind JavaFX SceneBuilder
Procesul de design al unei interfețe grafice folosind JavaFX SceneBuilder începe cu alegerea unui fișier container sau panou (engl. Pane) în care se vor insera nodurile (elementele constitutive ale interfeței grafice). Introducerea nodurilor în cadrul panoului se face trăgând în suprafața de lucru elementele grafice. După introducerea nodurilor se specifică clasa controller, se selectează nodurile și se introduc pentru fiecare din ele metodele event handler (care gestionează evenimentele), aflate în cadrul clasei controler, din panoul Properties secțiunea Code. Nodurile care se dorește a fi manipulate în clasa controler primesc și un identificator fx:id în cadrul interfeței, după care se face importul nodului în clasa controler.
În continuare, pentru exemplificarea modului de lucru cu acest program voi prezenta cum am creat un formular din cadrul aplicației, reprezentat în figura 2.11. În prima faza am ales containerul AnchorPane care permite „ancorarea” nodurilor copil la poziția dorită în cadrul său. Se poate observa în cadrul panoului Document nodurile și ierarhia lor, de unde putem trage concluzia că panoul AnchorPane este nodul părinte și toate celelalte noduri prezente în formular sunt noduri copil. În secțiunea controler am introdus în câmpul Controller Class clasa controler asociată formularului, adică controler.clientiFormController. În partea dreapta în panoul Inspector în secțiunea Code, se observă că butonul selectat Nou, are fx:id addBt și în cadrul câmpului On action este specificată metoda handleAddButton, ceea ce însemnă ca la apariția unui eveniment de tip ActionEvent la nivelul acestui buton (apăsarea butonului) metoda va gestiona evenimentul. În mod similar și celelalte butoane au primit fx:id-uri și au atașate metode de gestionare a evenimentelor în câmpul On Action.
Figura 2.11 Designul formularul Clienți in JavaFX SceneBuilder
2.2.4 Realizarea rapoartelor in TIBCO Jaspersoft Studio
Pentru exemplificarea modului în care am lucrat cu Jasper Studio voi prezenta în continuare crearea raportului factura ce reprezintă o factura pe care o generează o operațiune de rezervare sau închiriere. Deoarece formularul are ca sursă de date o bază de date, în prima fază am realizat conexiunea cu baza de date. După realizarea conexiunii cu baza de date, se alege formatul formularului. Pentru a introduce câmpurile în view-ul Outline este necesară introducerea interogării SQL, case va fi executată de program și care va extrage automat câmpurile (coloanele) care ne interesează din interogare. Interogarea SQL aferentă raportului factura este:
SELECT rezervarihotel.facturi.data,
rezervarihotel.facturi.total_cu_tva,
rezervarihotel.facturi.idfactura,
rezervarihotel.persoane.nume,
rezervarihotel.persoane.prenume,
rezervarihotel.persoane.tip_document,
rezervarihotel.persoane.seria_document,
rezervarihotel.persoane.adresa,
rezervarihotel.rezervari.total_nopti,
rezervarihotel.camere.numar,
rezervarihotel.camere.tarif_zi,
rezervarihotel.facturi.total,
rezervarihotel.facturi.total_cu_tva,
rezervarihotel.facturi.tva,
rezervarihotel.facturi.total_tva
FROM rezervarihotel.facturi
INNER JOIN rezervarihotel.rezervari ON
rezervarihotel.facturi.idrezervare = rezervarihotel.rezervari.idrezervare
INNER JOIN rezervarihotel.clienti ON
rezervarihotel.rezervari.idclient = rezervarihotel.clienti.idpersoana
INNER JOIN rezervarihotel.persoane ON
rezervarihotel.clienti.idpersoana = rezervarihotel.persoane.idpersoana
INNER JOIN rezervarihotel.camere ON
rezervarihotel.rezervari.idcamera = rezervarihotel.camere.idcamera
WHERE
rezervarihotel.facturi.idfactura = $P{idFactura}
Figura 2.12 Formularul factura in Jaspersoft Studio.
Deoarece formularul creat trebuie sa afișeze informații din cadrul aplicației Java, este necesar ca interogarea sa conțină și un parametru variabil ce va primi valori din aplicația Java. Acest lucru se face introducând un nou parametru în interogare și adăugând-ul la finalul interogării printr-o clauză WHERE care va filtra înregistrările din baza de date, afișând doar pe cele ce corespund valorii parametrului. În cazul formularului factura, parametrul idFactura este parametru care va primi valori din aplicație, iar interogării SQL i s-a adăugat la final clauza WHERE rezervarihotel.facturi.idFactura = $P{idFactura}. Adăugarea coloanelor în raport se face trăgând elementele în fereastra de lucru. După completarea cu celelalte elemente raportul factura în modul design va arata ca în figura 2.12.
Pentru executarea raportului din cadrul aplicației Java a fost necesară importarea bibliotecii JasperReports Library în cadrul structurii proiectului din mediul de dezvoltare.
Capitolul 3 – Prezentarea aplicației
Aplicația are drept scop gestionarea rezervărilor/închirierilor din cadrul unui hotel sau a unei alte structuri de cazare și este realizată folosind limbajul de programare Java alături de sistemul de baze de date MySQL. Aceasta aplicație este destinată personalului dintr-un hotel sau dintr-o altă structură de cazare pentru a facilita evidența rezervărilor sau închirierilor de camere.
Interfața grafică a aplicației oferă utilizatorului următoarele funcționalități:
Evidenta salariaților: crearea conturilor utilizatorilor, afișarea informațiilor despre aceștia, modificarea datelor despre clienți al datelor de intrare în aplicație precum și al statutului salariatului;
Gestionarea camerelor din cadrul hotelului și anume: introducerea, ștergerea și modificarea camerelor în baza de date;
Evidenta clienților: introducerea lor în baza de date, modificarea datelor referitoare la aceștia, ștergerea lor din baza de date;
Efectuarea operațiunilor de rezervare și închiriere: introducerea rezervărilor sau închirierilor în baza de date, modificarea sau ștergerea lor din baza de date;
Accesul diferențiat al utilizatorilor aplicației cu restricționarea anumitor facilități în cadrul sistemului în funcție de privilegiile definite la crearea contului de utilizator;
Calculul automat al costului unei rezervări/închirieri;
Facturarea închirierilor și listarea facturilor;
Generarea de rapoarte referitoare la clienți și camere;
Afișarea grafică a statisticilor referitoare la gradul de ocupare al hotelului pe o anumită perioadă de timp specificată de utilizator;
Afișarea grafică a situației camerelor, cu posibilitatea de afișare a perioadei în care camera este rezervată sau închiriată.
3.1 Accesul în sistemul informatic
Pentru a putea utiliza aplicația în condiții de control al accesului la anumite funcționalități accesul a fost prevăzut cu un sistem securizat. La lansarea în execuție se afișează fereastra de acces în aplicație care se prezintă ca în figura 3.1. Intrarea în aplicație se face introducând date de acces ce au fost definite în cadrul aplicației și apăsând butonul login. Dacă datele au fost introduse corect se va intra în sistemul informatic, dacă nu, se va afișa un mesaj de eroare sub forma „Utilizatorul și/sau parola sunt greșite” precum se arată în figura 3.2. Dacă datele de acces au fost introduse corect atunci programul va afișa fereastra principala ca în figura 3.3. Dacă se apasă butonul Cancel aplicația se va termina imediat și fereastra login se va închide.
Figura 3.1 Fereastra login Figura 3.2 Fereastra login cu mesajul de eroare
3.2 Elementele interfeței grafice cu utilizatorul
După cum se poate observa în figura 3.3, interfața grafică a aplicației conține următoarele elemente: bara de meniu, bara de instrumente, fereastra de lucru și pe care le voi prezenta detaliat în continuare. Navigarea prin funcțiile aplicației se face selectând un buton din bara de instrumente sau un element din bara de meniu.
Figura 3.3 Elementele interfeței grafice a aplicației
Bara de meniu conține elementele următoare:
Meniul Fișier, conține itemul Ieșire care termină execuția aplicației;
Meniul Configurează conține elementele Acces Utilizatori, care configurează accesul utilizatorilor în sistemului informatic și Camere, care configurează camerele structurii de cazare;
Meniul Adaugă , conține elementele Adaugă rezervare, care afișează în fereastra de lucru formularul pentru gestiunea rezervărilor/închirierilor și Adaugă client ce afișează formularul pentru gestiunea clienților.
Meniul Rapoarte, care prezinta itemul Raport camere care afișează lista camerelor și Raport Clienți care afișează lista clienților;
Meniul Ajutor are un singur item – Despre, care afișează o fereastră cu informații despre aplicație.
Bara de instrumente conține elementele următoare:
Butonul Rezervări aduce în suprafața de lucru formularul pentru gestionarea rezervărilor/închirierilor;
Butonul Clienți, afișează formularul pentru gestionarea portofoliului de clienți;
Butonul Facturi, inserează în suprafața de lucru formularul pentru gestionarea facturilor;
Butonul Arhivă, afișează formularul Arhivă, care permite căutarea avansată în arhiva de rezervări și închirieri;
Butonul Camere, afișează în mod grafic camerele și situația acestora;
Butonul Statistici, prezintă statisticile referitoare la gradul de ocupare pe o anumită perioadă de timp;
Butonul Ieșire, care închide aplicația;
O etichetă ce afișează utilizatorul autentificat și nivelul de acces asociat acestuia.
Butoanele din cadrul barei de instrumente prezintă tooltip-uri care oferă informații despre rolul sau funcționalitatea unui anumit buton. Pentru afișarea unui tooltip este necesar să poziționam cursorul pe butonul care ne interesează.
Fereastra de lucru reprezintă acea zona în care se vor încărca formularele din cadrul aplicației prezentate în continuare.
3.3 Prezentarea formularelor aplicației
Datorită faptului ca aplicația se conectează la o baza de date și efectuează operații în baza de date, elementele predominate ale interfeței sunt formularele. Astfel aplicația prezintă un set de formulare asociate operațiunilor efectuate în baza de date.
Figura 3.4 Formularul Utilizatori
Formularul Utilizatori, cu ajutorul căruia se introduc, se șterg și se modifică informațiile despre utilizatorii sistemului informatic. Formularul conține câmpuri în care se introduc datele personale ale utilizatorilor (nume, prenume, document de identitate, seria și numărul actului de identitate, adresa, telefonul, email-ul și salariul), cât și informații legate de accesul în sistem (drepturi acces, login, parola, status) după cum se poate observa în figura 3.4. De menționat este faptul că aplicația este concepută să specifice nivelul de acces pe care îl are fiecare utilizator și anume: Administrator (utilizator cu drepturi depline) sau Utilizator (utilizator cu accesul restricționat la meniul Configurează). De asemenea, pentru a restricționa accesul unui utilizator nu este nevoie sa-l ștergem din baza de date, ci doar i se poate schimba statusul cu „D”(dezactivat). Pentru introducerea unui noi angajat se selectează butonul Nou, se completează câmpurile disponibile și, la final, se apasă butonul Salvează. Modificarea unei înregistrări se face prin selecția acesteia din cadrul tabelului, modificarea informațiilor din câmpurile dorite si, la final, prin apăsarea butonului Modifică. Ștergerea unei înregistrări se face prin selectarea ei si prin apăsarea butonului Ștergere.
Formularul Camere efectuează operațiuni în baza de date asupra structurii camerelor unității de cazare. Formularul facilitează operațiuni de introducere, ștergere, modificare a informațiilor referitoare la camere și dispune de un câmp de căutare rapida a camerelor după etajul la care se află (figura 3.5). Formularul dispune de câmpuri în care se introduc informații despre camere (număr camera, etajul, descrierea camerei, caracteristicile camerei, tariful, statusul camerei și tipul camerei). Pentru introducerea unei noi camere se apasă butonul Nou, se completează câmpurile disponibile și se apasă butonul Salvează. Pentru editarea unei înregistrări, se selectează din tabel înregistrarea cu un click, având ca efect popularea câmpurilor din stânga, se operează modificările se apoi se salvează apăsând butonul Modifica. Ștergerea unei înregistrări se face prin selectarea acesteia din cadrul tabelului și prin acționarea butonului Șterge.
Figura 3.5 Formularul Camere
Formularul Clienți (fig. 3.6) permite introducerea, ștergerea, modificarea și afișarea datelor referitoare la clientelă. În formular se introduc informații referitoare la clienți: numele și prenumele clientului, tipul documentului de identitate, seria documentului de identitate, adresa clientului, telefonul, email-ul și codul clientului. Pentru adăugarea unui nou client se selectează butonul Nou, se completează toate câmpurile, cu excepția Cod Client care este generat în mod automat. Modificarea unei înregistrări se face prin selectarea înregistrării, care va avea ca rezultat completarea câmpurilor cu datele aferente înregistrării și după operarea modificărilor prin apăsarea butonului Modifică, pentru efectuarea modificărilor în baza de date.
Figura 3.6 Formularul Clienți
Formularul Rezervări/Închirieri (fig. 3.7) facilitează gestiunea rezervărilor/închirierilor. Se pot introduce, modifica, șterge operațiunile de rezervare sau închiriere.
Figura 3.7 Formularul Rezervări/Închirieri
Formularul conține câmpurile in care se introduc informațiile necesare efectuării unei operațiuni de închiriere sau rezervare(numărul camerei, numele și prenumele clientului, numele si prenumele angajatului care efectuează operațiunea, tipul operațiunii, data operațiunii, data check-in, data check-out, numărul nopților și statusul operațiunii). Efectuarea unei noi rezervări/închirieri se face cu butonul Nou, se selectează o cameră prin acționarea butonului de căutare din dreptul câmpului Camera care va aduce în prim plan un formular pentru selecția unei camere disponibile (figura 3.8), selectarea înregistrării făcându-se prin click dublu pe o cameră din tabel. Pentru selectarea unui client din baza de date se apasă butonul de căutare din dreptul câmpului client, apoi se alege clientul din formularul care se afișează (figura 3.9), iar dacă nu se găsește în baza de date se adaugă un client nou, cu ajutorul butonului Client nou, care va deschide formularul pentru introducerea unui nou client (figura 3.10). După completarea restului de câmpuri, cu excepția câmpului Număr nopți, care este autogenerat, se acționează butonul Salvează. Formularul Rezervări/Închirieri permite și generarea de facturi pentru o operațiune prin acționarea butonului Adaugă factura, care va avea ca rezultat afișarea în prim plan unui nou formular (Adaugă factura) unde se calculează automat costul unei închirieri, având ca efect completarea câmpurilor ca în figura 3.11.
Figura 3.8 Formularul de selecție al camerei
Figura 3.9 Formularul Selectează clientul
Figura 3.10 Formularul Adaugă client nou
Figura 3.11 Formularul Adaugă factura
Mai trebuie precizat că tabelul din cadrul formularului afișează doar rezervările/închirierile active sau anulate și permite ștergerea doar a rezervărilor anulate, pentru a nu stoca date irelevante în baza de date.
Formularul Facturi (figura 3.12) afișează facturile din baza de date și permite modificarea, ștergerea sau listarea acestora.
Figura 3.12 Formularul Facturi
Selectarea unei facturi se face cu un singur click pe înregistrarea din tabel, având ca efect completarea automată a câmpurilor din stânga cu datele aferente facturii selectate. Datele facturii se pot modifica prin editarea câmpurilor și în final prin apăsarea butonului Modifica, având ca efect salvarea modificărilor în baza de date. Listarea sau ștergerea unei facturi se face prin folosirea butoanelor cu imagini sugestive din cadrul coloanei Acțiune.
Formularul Arhivă (figura 3.13) oferă informații despre toate operațiunile de rezervare/închiriere din baza de date pe o anumită perioadă de timp. Formularul prezintă și un câmp de căutare al înregistrărilor după numele sau prenumele clientului.
Figura 3.13 Formularul Arhiva
Fereastra Situația Camerelor (figura 3.14) afișează în mod grafic numărul camerei, tipul camerei și situația în care se găsește fiecare cameră din cadrul hotelului. Camerele sunt reprezentare în mod grafic prin butoane având culori ce sugerează starea în care acestea se găsesc:
Butonul de culoare verde reprezintă o cameră disponibilă;
Butonul de culoare galbenă reprezintă o cameră rezervată;
Butonul de culoare roșie reprezintă o cameră închiriată.
Reprezentarea camerelor sub formă de butoane are drept scop afișarea de informații suplimentare referitoare la situația camerelor. Așadar, dacă dorim informații despre perioada în care o cameră este rezervată sau închiriată trebuie doar apăsat butonul ce reprezintă camera care ne interesează și in calendarul de alături va fi marcată automat perioada în care camera este rezervată sau închiriată prin culoarea galben pentru camere rezervate și roșu pentru camerele închiriate.
Același informații sunt oferite și prin tooltips-urile aferente butoanelor care reprezintă camerele, care sunt afișate prin poziționarea cursorului asupra unui buton ce reprezintă o cameră.
Figura 3.14 Formularul Situația camerelor
Formularul Statistici are rolul de afișare a graficului cu gradul de ocupare al hotelului pe o anumită perioadă de timp specificată de utilizator. Graficul afișează în fiecare zi a perioadei selectate numărul camerelor închiriate precum se poate observa în figura 3.15.
Formularele care execută operații în baza de date conțin un tabel ce afișează înregistrările din baza de date și care se actualizează automat după o operațiune de ștergere, introducere sau modificare a datelor unei înregistrări.
Figura 3.15 Formularul Statistici
Operațiunile de ștergere se execută după ce operațiunea este confirmată și în fereastra de dialog ce apare ce rezultat al acțiunii de ștergere (figura 3.16).
Figura 3.16 Fereastra de confirmare a ștergerii unei înregistrări
3.4 Facturi și rapoarte
Aplicația oferă posibilitatea de a genera rapoarte referitoare la camerele cât și la clienții hotelului care pot fi vizualizate, salvate în format pdf sau listate. Raportul referitor la camere ne afișează informații relevante despre camere sau clienții hotelului.
Pentru a afișa raportul referitor la camerele hotelului se selectează din bara de meniu a aplicației meniul Rapoarte, apoi se selectează itemul Raport camere, având ca rezultat afișarea unei ferestre cu raportul respectiv precum în figura 3.17. Pentru a genera un raport referitor la clienți se alege din bara de meniu Rapoarte și apoi itemul Raport clienți având ca efect afișarea unei ferestre ca în figura 3.18.
O altă facilitate pe care o oferă aplicația este posibilitatea de a genera facturi pentru o operațiune de închiriere. Pentru afișa o factură se alege din tabelul cu facturile din cadrul formularului Facturi, iar din coloana Acțiune se acționează butonul listare. Ca urmare a acestei acțiuni se va afișa o fereastră precum în figura 3.19 care ne permite vizualizarea, salvarea în format pdf a facturii sau listarea acesteia operațiuni ce se efectuează cu ajutorul butoanelor prezente în bara de instrumente a ferestrei.
Figura 3.17 Fereastra cu raportul Camere
Figura 3.18 Fereastra cu raportul Clienți
Figura 3.19 Exemplu de factura pe care aplicația o generează
Ieșirea din aplicație
Pentru a ieși din aplicație se poate proceda fie prin acționarea butonului Ieșire din bara de instrumente. Acțiunea va avea ca efect apariția unei ferestre de dialog privind confirmarea părăsirii aplicației ca în figura 3.20. De asemenea aplicația se poate închide si prin acționarea butonului de închidere al ferestrei principale a aplicație.
Figura 3.20 Fereastra de dialog la ieșirea din aplicație
Concluzii
Bibliografie
Năstase, P. (colectiv), Baze de date în Microsoft Access 2000, Editura Teora, București 2003;
Ramez, E., Shamkant B., Fundamentals of Database Systems Seventh Edition, Editura Pearson, USA 2016;
DuBois, P., MySQL Fourth Edition, Editura Pearson, 2008;
Giulvezan, C., Mircea G., Târnăveanu D. – Baze de date: Teorie si practica. Access, VBA si SQL, Editura Universității de Vest, Timișoara, 2009;
Tanasă, S., Andrei S., Olaru C., Java de la 0 la expert – Ediția a II-a, Editura Polirom, Iași 2011;
DuBois, P., MySQL Fourth Edition, Editura Pearson, 2008;
http://community.jaspersoft.com/wiki/introduction-jaspersoft-studio;
https://www.mysql.com/products/workbench;
https://docs.oracle.com
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: În calitate de student al „Facultății de Calculatoare și Informatică Aplicată” din cadrul Universității „Tibiscus”, încă din primul an de studenție… [305481] (ID: 305481)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.