Sistem Suport Pentru Instruire In Domeniul Stiintelor Umaniste
Lucrare de licență
Sistem suport pentru instruire in domeniul stiintelor umaniste
Cuprins
1. Introducere
2. Bazele teoretice utile în procesul de realizare a unui sistem de instruire asistată de calculator 7
2.1. O perspectiva sintetică asupra problemei instruirii în general
2.2 Direcții de cercetare și dezvoltare în instruirea asistată pe calculator
2.3 Comparație între SistemeleTradiționale și Instruirea asistata pe calculator 8
3. Tehnologi 9
3.1 MySQL Workbench
3.2 Apache Tomcat
3.3 JAVA
3.3.1 Introducere
3.3.2 Dezvoltarea aplicațiilor utilizând Java
3.3.3 Platforme de lucru în Java
3.3.4 Declararea obiectelor și claselor
3.3.5 Distrugerea obiectelor
3.3.6 Clase
3.3.7 Constructori
3.3.8 Variabile
3.3.9 Metodele
3.3.10 Interfețe
3.4 XML-DOM
Noduri DOM
Nodul arbore din DOM XML
Nodurile parinte, copil si frați
Parsarea documentelor XML cu DOM
Crearea arborelui
Concluzii
3.5 Lucrul cu baze de date – JDBC
3.5.1 Rolul bazelor de date
3.5.2 JDBC
3.5.3 Crearea unei aplicații JDBC
3.6 Html
3.6.1 JavaScript
3.6.2 JQuery
3.7 Java Server Pages
3.8 Java Servlet
4.Modelarea UML a sistemului
4.1 Enunț
4.2 Obiective
4.3 Arhitectura
4.3.1 Arhitectura Soft a unei aplicatii
4.3.2 Arhitectura fizică a aplicațiilor Java
4.4 Diagrama claselor
Atribute
Operațiuni
4.5 Use Case-uri
5.Prezentarea aplicației
6.Concluzii
Introducere
Lucrarea de față are ca scop realizarea unui site web pentru instruirea în domeniul științelor umaniste, mai exact un curs de limba engleză.
În zilele noastre calculatorul are un rol din ce în ce mai important, principalul fiind cel informativ, educational. Pe baza acestui fapt, tot mai multe școli, licee, universități din întreaga lume au procurat diferite moduluri și programe de studiu online. S-a dovedit științific faptul că omul asimilează mult mai bine informațiile într-un mod interactiv, prin exemplificări, jocuri, imagini etc, iar mai nou și prin informații electronice.
Pentru a exemplifica modul în care informațiile electronice pot înlocui mijloacele tradiționale de învățare, precum cărțile, manualele, atlasele și chiar bibliotecile, această lucrare prezintă transpunerea unui curs de limba engleză-începatori pe calculator. Redarea informațiilor sub această formă permite o explorare individualizată, în funcție de interesul utilizatorului.
Cursul online este alcătuit din lecții, exerciții corespunzătoare fiecărei lecții, dar și un dicționar, atât de folositor în învățarea unei limbi străine.Lecțiile prezentate nu se bazează neaparat pe gramatica limbii (existând însă și câteva astfel de lecții), ci în principal pune accentul pe informații cu care un om se întâlnește zilnic. Cu astfel de informații ne putem întâlni pe stradă, acasă sau chiar într-o vacanță în altă țară, putând astfel să punem în practică informațiile asimilate. Pentru cineva care este la începutul cunoșterii unei limbi străine nu este esențial să retina foarte multe reguli de gramatica, ci să cunoscă cât mai multe cuvinte din vocabular și expresiile de bază. Gramatica va deveni și ea o preocupare, însă într-o altă etapă.
Ideea acestei lucrări a venit dupa o tema primită la facultate, implementarea unor teste grilă online. De aici a venit idea extinderii acestor teste la un întreg curs. Limba engleză a fost aleasă pentru ca este una dintre cele mai vorbite limbi străine și a devenit un atu cunoașterea eii.
2. Bazele teoretice utile în procesul de realizare a unui sistem de instruire asistată de calculator
2.1. O perspectiva sintetică asupra problemei instruirii în general
Instruirea este activitatea de bază din cadrul procesului de învațare, potrivit obiectivelor pedagogice emise la nivel de sistem. Acțiunile proiectate de către instructor au la bază patru operații: alegerea obiectivelor pedagogice, definirea conținutului, punerea în practică a acestuia și asigurarea evaluării activității.
Conceptul de instruire are o sferă mai restrânsă în raport cu educația (dezvoltarea permanentă a personalității), dar mai largă decât învățarea pentru ca include mai multe tipuri de muncă intelectuală (forme extradidactice și extrașcolare ; cu resurse substanțiale ; directe și indirecte ; de natură morală, tehnologică).
2.2 Direcții de cercetare și dezvoltare în instruirea asistată pe calculator
Instruirea asistată de calculator este un procedeu didactic sau o tehnică de învățământ , care pune in evidență principiile de modelare și analiză cibernetică a instruirii, în conjunctura noilor tehnologii de comunicație si informatice, caracteristice societății din zilele noastre.
Asocierea dintre resursele pedagogice ale instruirii programate și resursele tehnologice ale calculatorului oferă acestui procedeu didactic ( Instruirea asistată de calculator ) caracteristici precum :
informatizarea activității de predare– învățare–evaluare ;
îmbunătățirea instruirii pe calculator cu ajutorul unor procese de : gestionare , documentare;
simulare automatizată interactivă a cunoștințelor și capacităților angajate în procesul de învățământ , conform documentelor oficiale de planificare a educației .
Tehnica instruirii pe calculator valorifică următoarele operații didactice:
organizarea informației conform cerințelor programei adaptabile la capacitățile fiecărui student ;
provocarea cognitivă a studentului prin secvențe didactice și întrebări care vizează depistarea unor lacune, probleme, situații problemă ;
rezolvarea sarcinilor didactice prezentate anterior prin reactivarea sau obținerea informațiilor necesare de la resursele informatice apelate prin intermediul calculatorului ;
realizarea unor sinteze recapitulative după parcurgerea unor teme , module de studiu ; lecții, grupuri de lecții, subcapitole, capitole, discipline școlare ;
asigurarea unor exerciții suplimentare de stimulare a creativității studentului .
2.3 Comparație între SistemeleTradiționale și Instruirea asistata pe calculator
În Tabelul 1 sunt analizate în antiteză componentele instruirii asistate pe calculator și cea tradițională.
Tabelul 1.Comparație între cele două tipuri de instruiri prezentate
3. Tehnologi
3.1 MySQL Workbench
MySQL Workbench oferă un instrument grafic pentru a lucra cu servere MySQL și baze de date. Acesta acceptă versiunile de MySQL Server 5.1 și mai sus. De asemenea, este compatibil cu MySQL Server 5.0, dar nu toate caracteristicile 5.0. Nu-l suport versiunile 4.x MySQL Server.
MySQL Workbench oferă cinci domenii principale de funcționalitate:
Dezvoltarea SQL: Vă permite să creați și să gestionați conexiunile la serverele de baze de date. MySQL Workbench oferă capacitatea de a executa interogari SQL pe baza de date folosind SQL Editor.
Modelarea datelor: Vă permite să creați schemele grafice ale bazei de date proprii și să editați toate aspectele bazei de date cu ajutorul Table Editor.
Administrarea serverului: Vă permite să administrați serverul MySQL prin administrarea utilizatorilor, efectuarea de copii de siguranță și recuperare a datelor, monitorizarea performanței serverului MySQL etc.
Migrarea datelor: Vă permite sa migrate de la baze de date precum Microsoft SQL Server, Sybase ASE, SQLite, SQL Anywhere, PostreSQL și altele la MySQL.Este posibila si migrarea de la variante mai vechi ale MySQL la cele mai noi.
Suport MySQL Enterprise: Suport pentru produse Enterprise precum MySQL Enterprise Backup și MySQL Audit.
MySQL Workbench este disponibil în două ediții, Community Edition si Commercial Edition.Community Edition este disponibilă gratuit, Commercial Edition oferă caracteristici Enterprise suplimentare, cum ar fi accesul la MySQL Enterprise Backup și MySQL Audit, la costuri reduse.
3.2 Apache Tomcat
Apache Tomcat (sau pur și simplu Tomcat, anterior, de asemenea, Jakarta Tomcat) este un server web open source dezvoltat de Apache Software Foundation (ASF).
Apache Tomcat versiunea 7.0 implementează specificațiile pentru Servlet 3.0 și Java Server Pages 2.2 din Java Community Process și include multe alte caracteristici suplimentare care o fac o platformă utilă pentru dezvoltarea și implementarea de aplicații și servicii web.
Există mai multe modalități pentru a seta Tomcat pentru a rula pe platforme diferite. Instalarea Tomcat pe Windows se poate face cu ușurință folosind Windows installer.
Instalare ca serviciu: Tomcat va fi instalat ca un serviciu Windows indifferent ce setare este selectată.Utilizând caseta de selectare, din pagina de setări, serviciul ca "auto" startup, Tomcat este pornit automat atunci când Windows pornește. Pentru o secturitate optimă, serviciul trebuie executat ca utilizator diferit, cu permisiuni reduse.
Locație Java: Programul de instalare va oferi un JRE implicit, utilizat pentru a executa serviciul. Programul de instalare utilizează regiștrii pentru a stabili calea de bază către Java6 și JRE, inclusiv JRE-ul instalat ca parte a JDK-ului complet. Atunci când rulează pe un sistem de 64 biți programul de instalare se va uita prima data după un JRE pe 64-bit și doar în caz că acesta lipseste va căuta unul pe 32 biți.
Deployment este termenul folosit pentru procesul de instalare a unei aplicații web în serverul Tomcat.Acesta poate fi realizat în mai multe feluri în cadrul serverului Tomcat.
Static – configurarea aplicației web are loc înainte de pornirea serverului
Dinamic – prin manipularea direct a aplicației web deja implementată (bazându-se pe caracteristica Auto-implementare) sau de la distanță, cu ajutorul aplicației web Tomcat manager.
Utilizarea serverului necesită fixarea a doi parametri sistem:
_ CATALINA HOME= calea la catalogul în care s-a instalat produsul – TOMCAT HOME;
_ JAVA HOME=calea la distribuția Java utilizată.
Verifcarea funcționării serverului Web tomcat se face apelând dintr-un navigator
pagina http://host:port unde:
host este numele calculatorului pe care rulează tomcat;
Portul implicit este 8080.
Reușita este ilustrată de imaginea motanului:
3.3 JAVA
3.3.1 Introducere
Java este un limbaj de programare orientat pe obiecte, proiectat pentru a fi portabil pe mai multe platforme și sisteme de operare. Dezvoltat de Sun Microsystems, care a fost preluat de Oracle, Java este modelat după limbajul de programare C++ și include carecteristici speciale care îl fac ideal pentru programele pe Internet. Cu toate ca limbajul imprumuta anumite elemente de la limbajul C++ modelarea obiectelor si executia codului este diferita.
În anii ’60, C++ a constituit fundamentul pentru un nou pas înainte în programare. Limbajul Java depășește multe din limitările limbajelor C și C++. Este un limbaj portabil aceasta însemnând că programele scrise în Java pot fi rulate pe mai multe tipuri de calculatoare. Programele scrise în Java pot fi atașate paginilor Web și executate pe calculatoarele utilizatorilor în momentul în care se încarcă pagina. În general nu contează ce fel de calculator sau program de navigare pe Internet execută peogramul Java. Ar trebui să meargă bine pentru orice program de navigare pe Internet. Aceasta este teoria deși nu se întâmplă întotdeauna așa în practică.
Cei familiarizați cu limbajele C/C++ vor descoperi că Java este un limbaj ușor de stăpânit și încorporează principiile de bază ale programării orientate pe obiect, deși elimină unele din construcțiile mai complicate, cum ar fi moștenirea multiplă și șabloanele.
3.3.2 Dezvoltarea aplicațiilor utilizând Java
Kitul de dezvoltare Java (JDK-Java Developer’s Kit) este o colecție de software de la firma Sun care cuprinde tot ce este nevoie pentru dezvoltarea plicațiilor Java.
Cu Java se pot crea două tipuri de programe: un applet sau o aplicație. Applet-rurile sunt programe speciale în Java care sunt executate în cadrul unui browser Web. O aplicație Java este un program independent de browser și poate rula ca un program de sine stătător. Applet-urile java nu sunt cu mult mai diferite de aplicațiile autonome în Java. Se poate să se înceapă dezvoltarea progră programele scrise în Java pot fi rulate pe mai multe tipuri de calculatoare. Programele scrise în Java pot fi atașate paginilor Web și executate pe calculatoarele utilizatorilor în momentul în care se încarcă pagina. În general nu contează ce fel de calculator sau program de navigare pe Internet execută peogramul Java. Ar trebui să meargă bine pentru orice program de navigare pe Internet. Aceasta este teoria deși nu se întâmplă întotdeauna așa în practică.
Cei familiarizați cu limbajele C/C++ vor descoperi că Java este un limbaj ușor de stăpânit și încorporează principiile de bază ale programării orientate pe obiect, deși elimină unele din construcțiile mai complicate, cum ar fi moștenirea multiplă și șabloanele.
3.3.2 Dezvoltarea aplicațiilor utilizând Java
Kitul de dezvoltare Java (JDK-Java Developer’s Kit) este o colecție de software de la firma Sun care cuprinde tot ce este nevoie pentru dezvoltarea plicațiilor Java.
Cu Java se pot crea două tipuri de programe: un applet sau o aplicație. Applet-rurile sunt programe speciale în Java care sunt executate în cadrul unui browser Web. O aplicație Java este un program independent de browser și poate rula ca un program de sine stătător. Applet-urile java nu sunt cu mult mai diferite de aplicațiile autonome în Java. Se poate să se înceapă dezvoltarea programelor cu un applet sau cu o aplicație, trcerea de la una la alta facându-se foarte ușor. Pentru că un applet este rulat din cadrul unui browser Web, el are avantajul unei ferestre existente și capacitatea de a răspunde evenimentelor de interfață cu utilizatorul prevăzute de browser. În plus, deoarece appleturile sunt proiectate pentru utilizarea în rețea, Java este mult mai restrictiv cu tipurile de acces pe care appleturile le pot avea la sistemul de fișiere decât cu aplicațiile non-rețea.
Sun a proiectat de la început limbajul Java pentru Internet. Un Intranet este o versiune de uz intern a Internetului. Un intranet utilizează acceași tehnologie, aceleași software și același echipament cu Internetul (în principal TCP/IP). Diferența între ele este că Internetul deține servere de informații aflate la distanțe foarte mari, controlate de alte organizații, iar în cadrul Intranetului serverele și calculatoarele client sunt controlate de firma care le administrează. În ultimii ani Intranetul a cunoscut o popularitate foarte mare pentru că oferă la un cost foarte mic o modalitate de întreținere și distribuire a informațiilor interne ale unei firme, intr-o formă ușor de utilizat.
Deoarece intranetul lucrează la fel ca Internetul, Java își găsește în acest caz un loc în intranetul firmelor. Toate tehnicile de lucru care se utilizează pentru aplicațiile Internet pot fi utilizate și aplicate și în intranet. Cu Java se pot crea aplicații care să ofere interfețe prietenoase pentru bazele de date, stocarea documentelor, controlul echipamentelor și așa mai departe, care să ruleze pe orice calculator, de la Macintosh la PC sau la stațiile de lucru UNIX.
Atunci când spunem despre un cod că este robust facem referire la fiabilitatea sa. Deși Java nu a eliminat codul nesigur, a reușit să facă mai accesibilă scrierea unui cod de înaltă calitate. Java elimină problemele de memorie care sunt obișnuite în limbaje cum ar fi C și C++. Java nu aceptă accesul direct la pointeri de memorie. De asemenea, Java efectuează verificări în timpul rulării programului pentru a se asigura că toate referirile la tablouri și șiruri de caractere se află între limitele fiecărui element. În alte limbaje de programare, multe dintre erorile logice apar din cauză că programele nu eliberează memoria pe care ar trebui să o elibereze sau eliberează aceeași memorie de mai mlte ori. Java efectuează o „curățenie” automată care eliberează memoria neutilizată, evitând necesitatea ca programul să elibereze memoria neutilizată.
JDK conține compilatorul Java, depanatorul și un vizualizator de appleturi cu ajutorul căruia appleturile pot rula în afara unui browser, precum și documentație și exemple de aplicații.
Deci, un program Java compilat poate fi rulat pe orice platformă care are instalată mașina virtuală Java (JVM – Java Virtual Machine). Programele scrise în Java pot fi portate deoarece codul sursa Java este compilat într-un limbaj intermediar. Intermediar pentru că face legatura între codul mașină (ce depinde de strcutura fizică a calculatorului sau a dispozitivului) și codul sursă scris.
Mașina virtuală Java este cea care ruleaza codul. În timp ce rulează codul, limbajul intermediar este transformat în cod mașină cu instrucțiunile specifice procesorului respectiv.
Mai jos sunt enumerate carcteristicile principale ale acetui limbaj, carateristici ce l-au facut să devină atât de popular, cunoscut și folosit:
Simplitate – moștenirea multipla, care era în C++, nu mai este aplicabilă în Java.
Roustete – elimină sursele frecvente de erori ce apar în programre din cauza pointerilor, administrare automată a memoriei și eliminarea pirederilor de memorie toate acestea fiind posibile din cauza unui mecanism ce rulează în “spate” numindu-se Garbadge Collector;
Neutrailtatea arhitecturală a componentelor fizice – rularea unei aplicații Java nu depinde de arhitectura fizică a computer-ului pe care lucrează. JVM având rolul să abstractizeze și să ofere acest lucru;
Este compilat și interpretat – aceasta este caracteristica ce-l face să fie eficient în ideea de portabilitate;
Protabilitate: Fie că e vorba de sistemul de operare Windows, iOS, Linux, Android un program scris în limbajul Java va rula pe aceste sisteme.
3.3.3 Platforme de lucru în Java
O multitudine de tipuri de aplicații se pot dezvolta folosind limbajul Java. Pentru a face posibil acest lucru s-au dezvoltat platformele de lucru, ce reprezintă librarii scrise în limbajul Java, folosite pentru dezvoltare de aplicații pentru anumite categorii (web, dispositive mobile, servicii windows, etc).
Acestea sunt:
J2SE (Standard Edition) – Este patforma standard de lucru ce oferă posibilitatea pentru crearea de aplicații indepente si applet-uri. Tot aici este inlcusă și tehnologia Java Web Start ce furnizează un mod de a lansa și instala foarte ușor programele Java scrise pentru web;
J2ME(Micro Edition) – Această platformă ajută la crearea de conținut pentru dispozitivele mobile;
J2EE(Enterprise Edition) – Această platformă ofera posibilitatea dezvoltarii oricărui tip de aplicații, până la cele mai complexe. Aici se gasește suportul pentru a dezvolta aplicații web bazate pe servlet-uri, pagini JSP;
3.3.4 Declararea obiectelor și claselor
Un obiect în Java se face prin instanțierea unei clase. Există mai mulți pași când se instanțiază un obiect:
Declararea tipului acelui obiect
LessonRepository repository;
Instanțiere – care se realizează prin utilizarea operatorului new. În acest moment se va crea obiectul în memorie:
repository = new LessonRepository();
Odata ce s-a creat obiectul, acesta poate fi folosit în mai multe sensuri: aflarea unor informații despre obiect, schimbarea stării obiectului, executarea unor acțiuni.
3.3.5 Distrugerea obiectelor
În C++ dezvoltatorul trebuie să gestioneze obiectele alocate și atunci când nu mai este nevoie de ele să le distrugă. Însă se părea că acest mod de lucru a generat foarte multe probleme întrucât apareau erori frecvente de corupere de memorie neștiindu-se exact cauza lor.
În Java dezvoltatorul nu mai are responsabilitatea dsitrugerii obiectelor în mod explicit. În momentul rulării unui program, JVM luând decizia când un anumit obiect nu mai este folosit să poată fi șters din memorie. Acest proces de curățare poartă numele de Garbage Collector sau GC. Un obiect este șters din memorie atunci și numai atunci când nu mai există o referință la acesta.
GC-ul funcționează periodic și se declanșează când se întâmplă anumite acțiuni. Odată intrat în acțiune el scanează dinamic memoria programului Java ce se află în execuție și marchează cele obiecte care au referințe directe sau indirecte. După ce toate obiectele din memorie au fost parcurse cele nemarcate sunt eliminate din memorie.
Înainte ca un obiect să fie șters din memorie, GC îi dă posibilitatea acestui obiect să-și curețe din resursele folosite. Acest lucru făcându-se prin implementarea unei metode speciale numite finalize.
3.3.6 Clase
Clasele reprezintă “celula” unui sistem soft. Așa cum corpul uman la nivlul cel mai jos este de fapt fomat din celule.
Când Alan Kay a menționat ideea de design obiect orientat, metafora ce o avea în minte era aceea a unui sistem biologic format din multe celule ce treuie să comunică între ele folosind mesaje. Același lucru trebuie să se întample și în sistemul soft: clase care trimit mesaje între ele. Mesajele la randui putând fi reprezentate tot ca și clase.
Declararea unei clase are urmatoarea formă:
[public][abstract][final] Clasa [extends ClasaDeBaza] [implements Interfata]
{
/*corpul clasei*/
}
Public – Implicit o clasa poate fi folosito doar de clasele care se află în același pachet cu clasa respective. Când se pune modificatorul de protecție public această clasă poate fi folosită de orice altă clasă, indiferent de pachetul în care se găsește;
Abstract – este modul e declarare a unei clase abstracte, sau șablon. O clasă abstractă nu poate fi instanțiată, fiind folosită doar ca și clasă de bază pentru alte clase ce doresc să o extindă.
Final – o clasă declarată ca final nu mai poate fi moștenită de nici o altă clasă. Dacă e să se considere idea de performanță atunci când JVM vede o clasa declarată ca finala nu mai face anumite verificări pe care altfel le-ar fi făcut.
Extends – este modul prin care o clasă moștenește o altă clasă. În Java, spre deosebire de C++, moștenirea este simplă adică o clasă nu poate extinde mai mult de o clasă.
Corpul clasei – poate conține mai multe elemente: declararea și inițializarea variabilelor instantă, declararea și implementarea constructorilor, declararea și implementarea metodelor instanță și declararea claselor imbricate;
3.3.7 Constructori
Constructorii unei clase sunt niște metode speciale care au același nume cu cel al clasei, nereturnând nici o valoare și fiind folosiți pentru inițializarea obiectelor. Mai jos este un exemplu de contructor cu 4 parametrii. Înauntrul constructorului se ințializează niște variabile:
public Lesson(int id, String title, ArrayList<String> content, String image) {
mId = id; mTitle = title; mContent = content;
mImage = image;
}
O clasă poate avea unul sau mai mulți constructori care treuie să difere prin lista de parametrii definiți. Astfel, sunt permise diverse tipuri de inițializări ale obiectelor la crearea lor.
Constructorii impliciti sunt creați automat de compiltor atunci când nu e declarat nici un contructor în acea clasa. Deci prezența constructorilor atunci când se scrie cod nu este obligatoriu, dar la rulare, Java va avea grijă să insereze contructorii fără de care nu ar putea să se creeze obiectele. Dacă în clasă se creează un constructor, constructorul implicit nu mai este pus de către compilator.
Adeseori în codul ce definește costructorul cuvântul cheie this este întâlnit. This este o variabila predefintă care face referință, în cadrul unui obiect, la obiectul propriu zis. Cuvântul cheie super se folosește când se face referința la instanța părintelui.
3.3.8 Variabile
Variabilele membre ale unei clase se declară de obicei înaintea metodelor, deși acest lucru nu este impus de către compilator. Mai jos este un exemplu de clasă care are rolul de a “transporta” date (un data carier). Se poate observa că câmpurile, variabilele clasei, sunt definite la începutul declarației clasei.
public class Lesson {
private int mId;
private String mTitle;
private ArrayList<String> mContent;
private String mImage;
public Lesson(int id, String title, ArrayList<String> content, String image) {
mId = id;
mTitle = title;
mContent = content;
mImage = image;
}
public int getId() {
return mId;
}
public String getTitle() {
return mTitle;
}
public ArrayList<String> getContent() {
return mContent;
}
public String getImage() {
return mImage;
}
}
Variabilele memebre ale unei clase se declară în corpul clasei și nu în corpul unei metode, fiind vizibile în toate metodele definite din clasă.
Declararea unei variabile presupune specificarea următoarelor detalii: numle variabilei, tipul de date al acesteia, modificatorul de access(public, protected, privat),dacă este constantă sau nu.
Dacă o variabilă e declarată publică atunci ea va putea fi accesată atunci când se va crea o intanță a clasei din care face parte. Dacă este protected și se află într-o clasă de bază atunci ea va fi vizibilă numai claselor ce exting clasa de bază în care se află variabila. Variabila private inseamnă că nu poate fi vazută și accesată decât de clasa în care este definită, nicăieri altundeva.
De asemenea o varabilă poate fi statică. Indiferent de numărul de instanțe, variabila va exista într-un singur loc. Deci, dacă o instanță modifică variabila statică alte instanțe ale aceleiași clase vor vedea variabila modificată.
3.3.9 Metodele
Metodele definesc comportamentul claselor. Metodele se pot regăsi strict în conținutul claselor, asta deoarece limbajul Java este un limbaj strict obiect – orientat. Metodele, ca și variabilele, au la rândul lor modificatori de access: public, protected și private.
O metodă pate avea diferte “forme”:
Static – adică este o metodă la nivelul clasei.Chiar dacă se creează multe instanțe dintr-o clasă, o singură metodă va exista indiferent de numărul de instanțe;
Abstract – o metodă abstractă nu conține implementare și trebuie să facă parte dintr-o clasă abstractă. Orice clasă ce va extinde clasa abstractă va trebui să implementeze această metodă.
Synchronized – este folosit în cazul în care se lucrează cu mai multe fire de executare (threads) iar metoda respectivă gestionează resurse comune. Are ca efect ecotruirea unui monitor care nu permite executarea metodei, la un moment dat, decât unui singur fir de execuție.
3.3.10 Interfețe
Interfețele au fost adăugate deoarece Java nu oferă suport pentru moștenire multiplă. S-a vrut să se găsească un mod prin care o clasa să se poată vedea că are anumite comportamente predefinite. Interfețele sunt un mod de a defini ceea ce o clasă poate face.
O clasă poate extinde mai mult de o interfața. De asemenea, interfețele conțin doar antete de metode, constant. Și în mod implicit toate metodele definite într-o interfață sunt publice.
Interfețele mai pot juca un rol foarte util,pe langă clasele abstracte, atunci când se face o abstractizare a unui concept. De exemplu, codul din modulul business.model.Repository conține interfața ILessonSummaryRepository, iar clasa LessonSummaryManager lucrează cu această interfață. Lucrează cu acestă interfață dar nu-i cunoaște detaliile de implementare. Interfața fiind implementată de clase ce se află în modulul Curs.Repository. În felul acesta s-a realizat decuplarea domeniului business de modul cum sunt stocate datele.
Limbajul Java este imens. Posibilitățile ce le oferă sunt nenumărate. Programarea obiect orientată nu face decât să orchestreze elementele definite mai sus astfel încât sistemul soft să fie mai ușor de întreținut și gestionat.
3.4 XML-DOM
XML Document Object Model (DOM) tratează datele XML ca un set standard de obiecte și este folosit pentru procesAREA de date XML în memorie. System.Xml oferă o reprezentare programatică de documente XML, fragmente, noduri sau seturi de nod. Se bazează pe World Wide Web Consortium (W3C) DOM nivelul 1 Core și recomandările DOM nivelul 2 Core.
Clasa XmlDocument reprezinta un document XML. Aceasta include membri pentru preluarea și crearea de toate celelalte obiecte XML. Folosind XmlDocument, și clasele sale asociate, puteți construi documente XML, încărca și accesa și modifica date, dar și să salvați modificările.
Clasa XML Document Object Model (DOM) este o reprezentare în memorie a unui document XML. DOM vă permite să citiți programatic, manipulați și modificați un document XML. Nu sunt capabilități pentru a modifica valorile unui atribut, conținutul unui element, sau capacitatea de a insera și elimina noduri cu XmlReader. Editarea este funcția de principală a DOM.
Noduri DOM
Potrivit DOM, totul într-un document XML este un nod.
DOM spune:
Întregul document este un nod de document.
Fiecare element XML este un nod element.
Textul din elementele XML sunt noduri text.
Fiecare atribut este un nod de atribut.
Comentariile sunt noduri comentariu.
Figura 3.4.1. Lesson2.xml
XML DOM vede un document XML ca un nod arbore. Toate nodurile din arbore au o relație unul cu altul.
Nodul arbore din DOM XML
XML DOM vede un document XML ca o structura arborescenta. Structura arbore se numește și nod arbore. Toate nodurile pot fi accesate prin intermediul arborelui. Conținutul lor poate fi modificat sau șters, și noi elemente pot fi create.
Figura 3.4.2. Structura arborescentă a fișierului Xml Lesson2.xml.
Nodurile parinte, copil si frați
Nodurile din arbore au o relație ierarhică între ele. Termenii părinte, copil, și frate sunt folosiți pentru a descrie relațiile. Nodurile părinți au copii. Copii de la același nivel sunt numiți frații (sau surori).
Într-un arbore, nodul superior este numit rădăcină.
Fiecare nod, cu excepția rădăcinii, are exact un nod părinte.
Un nod poate avea orice număr de copii.
frunză este un nod fără copii.
Frații sunt noduri cu același părinte.
Nodurile care sunt la același nivel, reprezentate în Figura 1 de nodurile „img”, „description”, „content” și „exercise”, sunt frați.
Deoarece datele XML sunt structurate într-o formă arborescentă, acesta poate fi traversate fără a cunoaște structura exactă a arborelui și fără să se știe de tipul datelor conținute.
Parsarea documentelor XML cu DOM
Parsarea unui document XML folosind DOM presupune încărcarea întregului document în memorie. După încărcarea documentului, parcurgerea documentului se poate face folosind relațiile de ordine relațiile de ordine ale structurii arborescente a XML-ului. În acest mod, se pot accesa cu ușurință părinții, copiii și frații oricărui element. Acest avantaj compensează cu consumul mare de memorie in momentul in care documentul este incarcat in memorie.Astfel, o lucrare intemeiata pe DOM este foarte posibil sa nu poate fi realizata in cazul unor documente XML foarte mari.Acest lucru este posibil si in cazul unor resurse de memorie foarte limitate.
Dupa realizarea parsării de tip DOM sunt întoarse elemente de tip generic ”Document”, DOM oferind și o serie de metode standard prin care i se pot accesa informațiile (elementele, textul și atributele).
La nivel de document avem ca principale metode urmatoarele:
getDocumentElement –întoarce elementul rădăcină al documentului;
getElementByID – accesează primul element cu ID-ul specificat.
getElementsbyTagName – returneaza o listă de noduri cu toate elementele cu numele specificat.
Rezultatul acestor metode este un obiect sau o lista de obiecte de tip Element asupra căruia se pot aplica operații precum:
getAttribute – întoarce valoarea aceslui atribut cu numele specificat în parametru.
getChildNodes – întoarce o lista cu elemente de tip Node care sunt copii elementului curent.
getNodeType – identifica tipul unui anumit nod.
Pentru o gestionare eficientă a documentelor XML este recomandată și utilizarea următoarelor funcții:
createElementNS – primește ca atribute un spațiu de nume și numele unui element și întoarce un nou element
appendChild – se adaugă un copil nodului (Document, Element) current
createAttributeNS – adaugă un atribut elementului current
createTextNode – construiește un nod de tip text
De aceste funcții și metode m-am folosit și în aplicația prezentată. În primul rând, pentru că avem nevoie de mai multe atribute în cadrul aceleași clase, am creat o funcție statică ce ne întoarce informațiile de care avem nevoie.
De asemenea, la fel am procedat și în cazul elementelor, obținute prin metoda getElementsByTagName apelată în funcția getElement().
Crearea arborelui
// 1. Crearea unui obiect DocumentBuilderFactory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
// 2. Crearea unui obiect DocumentBuilder
DocumentBuilder db = dbf.newDocumentBuilder();
// 3. Crearea arborelui corespunzator unui fișier specificat
Document doc = db.parse(fileExercise)
// Crearea unui arbore vid:
Document doc = db.newDocument();
Pentru crearea arborelui a fost nevoie și de anumite importuri:
Concluzii
DOM (Document Object Model) este bazat pe organizarea documentului sub forma de arbore (de aici și denumirea: din fisierul XML este creat un document modelat dupa forma unui arbore)
-avantaj: avem modelul deja creat
dezavantaj: modelul de arbore poate fi prea complex pentru ce avem nevoie
DOM încarcă tot fișierul XML în memorie și apoi se plimbă prin el
-avantaj: se poate trece de mai multe ori prin fișier
– dezavantaj: – se consumă multă memorie, existând posibilitatea să nu ajungă toată memoria în cazul fișierelor XML mari
– parsarea durează mai mult
DOM ofera o interfață către fișierele XML de nivel ridicat
DOM este un standard W3C
În concluzie, DOM este un parser mai complex, care face toata treaba în locul nostru: citește fișierul XML, creează un obiect din acest fișier și ne dă o referință către acest obiect (un document), pe care putem apoi să îl manipulăm dupa cum dorim.
3.5 Lucrul cu baze de date – JDBC
3.5.1 Rolul bazelor de date
Navigând în World Wilde Web, un lucru este evident-există aici o mare cantitate de informații. Multe companii utilizează baze de date relaționale pentru a gestiona datele din propriile lor situri Web. Bazele de date relaționale bazele de date în care datele sunt stocate în tabele și sunt legate între ele prin relații. O astfel de bază de date este locul ideal de stocare a volumelor mari de date accesibile pentru mulți utilizatori. Pentru intranet se poate utilzaza, de exemplu, o bază de date relațională ca “back end” pentru crearea aplicațiilor mai sofisticate.
3.5.2 JDBC
Această tehnologie este un API pentru limbajul de programare Java care definește cum un client poate accesa o baza de date. Acesta oferă metode pentru interogarea și actualizarea datelor într-o bază de date. JDBC este orientată spre baze de date relaționale. Astfel, cu ajutorul JDBC ne este la îndemână transmiterea de secvențe SQL către baza de date relațională cu care lucrăm. Este suficient să scriem un program folosind JDBC , iar acesta va ști să comunice cu drivere diferite, către baza de date fiind trimise secvențe SQL. Astfel, nu avem nevoie de programe diferite pentru accesul la diferite baze de date precum Oracle, Sybase, etc ci de unul singur.Portabilitatea programului o asigurăm dacă scriem programul sursă în Java. Avem, deci, combinația Java-JDBC , combinație demnă de luat în seamă în cazul în care lucrăm cu baze de date.
Facilitățile oferite de JDBC sunt: – Realizarea conexiunii cu baza de date.
– Executarea secvențelor SQL.
– Prelucrarea rezultatelor.
3.5.3 Crearea unei aplicații JDBC
Există șase etape principale implicate în construirea unei aplicații JDBC:
1. Includerea pachetelor – includrea pachetelor ce conțin clase JDBC necesare pentru programarea cu baza de date. De cele mai multe ori, incluzând java.sql.* va fi suficient
2. Înregistrarea driver-ului JDBC – Inițializarea unui driver pentru a putea deschide un canal de comunicare cu baza de date
Class.forName("com.mysql.jdbc.Driver");
3.Deschiderea unei conexiuni – Acest lucru preupune folosirea metodei DriverManager.getConnection() pentru a crea un obiect Connection, ce reprezintă conexiunea fizică cu baza de date, după cum urmează:
4.Executarea unei interogări – În această etapă este necesară folosirea unui obiect de tip Statement sau PreparedStatement pentru construirea si depunerea unei declarații SQL la baza de date, după cum urmează:
5. Obținerea și prelucrarea rezultatelor – Pentru preluarea datelor se folosește metoda ResultSet.getXXX(), după cum urmează:
6. Închiderea mediilor de lucru – În această etapă inchidem toate resursele folosite:
Punând cap la cap toate aceste etape obținem programul JDBC folosit și în aplicația prezentată. Spre exemplu, mai jos avem metodele InsertStatement și closeConnection ce respectă etapele construirii unei astfel de aplicații.
3.6 Html
Html este principalul limbaj folosit în aplicațiile web. Cu ajutorul acestui limbaj se poate crea partea de interfața a paginilor web. Sintaxa sa find asemenatoare cu sintaxa XML-ului. Numai ca nodurile și atributele limbajului HTML au o însemnătate specială pe care fiecare browser poate să o interpreteze.
Versiunea curentă a acestui limbaj este HTML5. Aceată versiune încorporând funcționalități ca playback video, drag-and-drop. Funcționalități care înainte se puteau folosi doar cu plugin-uri de browser (Flash player, Silverlight, Java FX). De asemenea HTML5 a introdus în API-ul (Application Programming Interface) și o serie de funcționalități ce ajută la crearea aplicațiilor web:
Desenare 2D cu element care se numește Canvas;
API care expune istoria din browser și permite paginilor să se foloseasca de browser history astfel încât funcționalitatea de la butonul Back să nu fie afectată;
API care permite unei aplicații web ca să se înregistreze pentru a folosi anumite protocoale și tipuri media;
Funcționalități noi ale HTML5:
Noi elemente semantice: <header>,<footer>,<section>;
Forms 2.0: îmbunătățiri în ceea ce privește elemental <input>, noi atribute au fost adăugate;
Stocarea informațiilor Local (Persistent Local Storage): această funcționalitate ajută să se salveze date local. Putând fi folosit de cele mai multe ori pentru a cache-ui datele. Această funcționalitate este foarte folosită în aplicațiile mobile;
Server Sent Events: HTML5 introduce evenimente care au loc între server-ul web și browsere;
Geolocation: Acum vizitatorii pot alege să permită paginii web să preia locația fizică a dispozitivului care rulează aplicația web;
Microdata: acestă funcționalitate permite crearea de vocabular propriu care extinde HTML5. Paginile web se pot scrie cu elementele noi de semantică create.
3.6.1 JavaScript
Paginile Web există într-un mediu client/server, adică, un server facilitează aceste pagini și o aplicație client ( în principal un browser ) le solicita și le afișează utilizatorilor.
De aceea, atunci când se vorbește de programare de pagini web este necesar să indice la care parte de programare se face referire( client sau server ) .
JavaScript rulează în mediul client.
JavaScript este un limbaj de programare, spre deosebire de HTML, care este un limbaj care permite descrierea paginii ( etalarea etichetelor ) . De exemplu , dacă se dorește să se pună o imagine pe pagină, se folosește HTML; dar dacă se vrea să se afle ce browser folosește utilizatorul paginii, atunci se folosește JavaScript.
Se spune că JavaScript este un limbaj de scripting pentru că se poate scrie codul direct în fișierul html.În mod normal sunt mici fragmente de cod (scripts) care apar alături de restul codului pe care îl conține pagina însuși.
Cu JavaScript se poate:
– Obține data și ora computerului utilizatorului
– Obține informații despre browser-ul folosit și să acționăm în consecință
– Modifică dinamic conținutul paginii, chiar și după ce a fost încărcată
– Scala o imagine în funcție de dimensiunea ecranului ( 640×480, 840×600, etc. )
– Valida informația introdusă de utilizator în formularele de pe pagină
3.6.2 JQuery
jQuery este o platformă de dezvoltare JavaScript, concepută pentru a ușura și îmbunătăți procese precum traversarea arborelui DOM în HTML, managementul inter-browser al evenimentelor, animații și cereri tip AJAX. jQuery a fost gândit să fie cât mai mic posibil, disponibil în toate versiunile de browsere importante existente.
Înainte să apară librării cum e Jquery programatorii trebuiau să scrie cod special pentru anumite funcționalități depinzând de tipul și versiunea de browser . De exemplu, în Internet Explorer în versiunile 6,7 API-ul ce expunea lucrul cu evenimente HTML diferit față de cum era expus în alte browsere ca Mozzila, Chrome. JQuery ascunde aceste diferențe, programatorul folosind doar un tip de sintaxă pentru a lucra cu eventimente HTML.
jQuery se poate folosi pentru a rezolva următoarele probleme specifice programării web:
selecții de elemente în arborele DOM;
parcurgere și modificarea arborelui DOM (incluzând suport pentru selectori CSS 3 și XPath simpli)
înregistrarea și modificarea evenimentelor din browser
manipularea elementelor CSS
efecte și animații
cereri tip AJAX
3.7 Java Server Pages
Ceea ce definește cel mai bine web-ul este interactivitatea. Comunicând cu un server, se poate găsi informația de care este nevoie. Ca să se înțeleagă JSP, trebuie avută o vedere clară la ceea ce se întamplă când browser-ul cere o pagina web. Figura de mai jos descrie ce se întamplă.
Fig. 3.7.1 Accesarea unei pagini HTML
Următorii pași au loc atunci când un browser face cererea unei pagini către un web server:
Atunci când se tastează url-ul în browser, browser-ul va încerca să-și de-a seama de url-ul introdus prin protocolul IP. După aceea, browser-ul va trimite o cerere Http request către ip-ul găsit ca să primescă pagina dorită;
Ca răspuns, web server-ul(la aplicațiile Jaca, web server-ul de obicei este TomCat) trimite un răspuns Http response cu text HTML. Imaginile și toate componentele care nu sunt text, ca sunet și video, vor aparea în pagină ca referințe;
Browser-ul primește răspunsul de la web server, interpretează conținutul HTML din pagină. Cere de la web server imaginile și toate componentele care nu sunt de tip text și apoi le va afișa.
Java Server Pages(JSP) este o tehnologie care ajută să se creeze paginile ce vor fi cerute în mod dinamic. În absența unei tehnologii ca JSP, actualizarea paginilor web ar trebui să se facă de mână. De asemenea, ar fi imposibil să se genereze HTML în funcție de anumite date.
Cu JSP o pagină web HTML nu există pe server. Ea este construită atunci când se face cererea paginii. Ce ajunge la browser este output-ul generat de către servlet, nu pagina JSP. Același servlet produce diferite output-uri depinzând de parametrii trimiși de Http request. Figura de mai jos descrie procesul în care JSP creează conținutul dinamic care va fi afișat în browser.
Figura 3.7.2. Generarea paginii dinamice
Deci când se generează o pagina dinamică au loc următorii pași:
Ca și cum s-ar trata de o pagină normală browser-ul va trimite o cerere Http request către web server.
Web server-ul este unul Java, cu extensii special construite să recunoască și să execute servlet-urile Java. Web server-ul recunoaște că s-a făcut o cerere către server pentru o pagină JSP și va forwarda această cerere către motorul(engine) JSP;
Motorul JSP încarcă pagina JSP dorită de pe disc și o convertește într-un servlet.
Motorul JSP compilează servelet-ul în cod executabil și forwardează cererea primită către o altă parte din server numită motorul servlet. Deci motorul JSP doar convertește pagina JSP în cod Java și recompilează servlet-ul dacă vede că pagina JSP s-a schimbat de când s-a cerut ultima oară;
Motorul servlet încarcă servlet-ul nou creat și îl execută. În timpul execuției servelt-ul produce conținut HTML. Acest conținut este trimis la web server care-l va pune în răspunsul HTTP.
Browser-ul va prelua HTML generat și-l va afișa. Pentru browser nu este nici o diferență între conținutul html creat dinamic sau cel static.
3.8 Java Servlet
Java Servlets este o tehnologie web pentru Java. A fost prima tehnologie de web pentru Java și multe tehnologii web au apărut de atunci.
Deși servlet-urile pot răspunde la orice tipuri de cereri, acestea sunt folosite pentru a extinde aplicațiile găzduite de servere de web, astfel încât acestea pot fi considerate ca applet-uri Java care se execută pe servere în loc de browserele web. Aceste tipuri de servlet-uri sunt omologul Java pentru celelalte tehnologii dinamice de conținut Web, cum ar fi PHP și ASP.NET.
În general se utilizează în:
Procesarea și păstrarea datelor depuse de un formular HTML
Furnizarea de conținut dinamic, precum rezultatele unei interogări de baze de date.
Din punct de vedere tehnic, un servlet este o clasă Java în Java EE conform cu Java Servlet , un standard pentru clasele Java, ce răspund unor cereri. Servlet-urile ar putea în principiu comunica prin orice protocol client-server, dar acestea sunt cel mai frecvent utilizate cu protocolul HTTP, astfel, un dezvoltator de software poate folosi un servlet să adauge conținut dinamic la un server de web folosind platforma Java. Conținutul generat de obicei este HTML, dar pot fi și alte date, precum XML.
Pentru a implementa și rula un servlet, se folosește un container de web. Un container web (de asemenea cunoscut ca un container de servlet) este, în esență, componenta unui server web care interacționează cu servlet-urile. Containerul web este responsabil pentru gestionarea ciclului de viață al servlet-urilor, maparea unui URL pentru un anumit servlet și garantarea faptului că solicitantul URL-ului are drepturi de acces corecte.
Apelarea servlet-ului se poate face:
din meniul File/Open al unui navigator;
ca referință într-un document html
Din documentul html pomenit anterior, apelarea clasei servlet se face uzual, prin intermediul atributului action a elementului form. Valoarea atributului este numele de apel al servlet-ului.
Prin Asynchronous JavaScript And Xml – AJAX un servlet se poate apela dintr-o funcție Javascript.
Legătura cu clasa servlet-ului se poate realiza
programat – prin adnotăari în codul servlet-ului;
descriptiv – în catalogul WEB-INF se editează fișierul web.xml.
Modul descriptiv: În fișierul web.xml apar elementele:
<servlet> leagă numele servlet-ului defnit în elementul <servlet-name> de clasa servlet-ului dat în elementul <servlet-class>
<servlet-mapping> defnește numele sub care servlet-ul se invocă din programul navigator.
Exemplu fisier web.xml din aplicația prezentată:
Modul programat: se bazează pe adnotarea javax.servlet.annotation.
4.Modelarea UML a sistemului
4.1 Enunț
Se dorește implementarea unei aplicații web ce vine în sprijinul celor care vor să învețe o limbă străină, mai exact limba engleză. Vor fi luate în calcul existența a doua tipuri de utilizatori: unul obișnuit, ce va putea accesa conținutul lecțiilor, exercițiilor dar și al unui dicționar lingvistic, iar al doilea tip de utilizator va fi un administrator ce va putea adăuga, modifica și șterge conținutul lecțiilor și exercițiilor, dar va putea și să adauge noi cuvinte în dicționar.
4.2 Obiective
Suntem conștienți că trăim într-o lume în care ne petrecem din ce în ce mai mult timp în fața calculatorului , explorând lumea online.Facem asta din simplu motiv că asta presupune locul nostru de muncă sau pentru că vrem să ne facem cumpăraturile, să socializăm cu persoane din din alte țări, orașe, sau chiar foarte aproape din punctul de vedere al locației, să urmărim filme, emisiuni și altele.Motive sunt foarte multe. Printre acestea se află si motivul educațional. Pe Internet găsim nenumărate cursuri, documente, cărti, fișiere media ce ne stau la dispoziție pentru a ne însuși cunoștiințte noi, sau pentru a le aprofunda pe cele existente.
Obiectivul principal al cursului prezentat este acela de a veni în ajutorul celor care îsi doresc să dobândească cunostiințe de limba engleză.Cu ajutorul tehnologiilor prezentate în capitolul anterior acest obiectiv a fost îndeplinit.
Astfel, utilizatorul poate urma lecțiile prezentate în curs pentru a învăța cât mai multe lucruri din cadrul acestora, iar pentru a-și fixa aceste cunoștiințe este preferabil ca lecțiile să fie urmate și de efectuarea exercițiilor. Pentru rezultate cât mai bune, exercițiile au același subiect ca și lecțiile.
Pentru cazul în care utilizatorul nu înțelege anumiți termeni a fost creat și un dicționar. Prezența acestuia este absolut necesară atunci când dorim să învățăm o limbă străină.
Un alt obiectiv este de a putea modifica conținutul lecțiilor sau a dicționarului. Prin autentificarea ca administrator acest lucru este posibil. Adminstratorul poate adăuga o lecție noua, iar pentru a respecta structura educațională a site-ului acesta trebuie să adauge și exercițiile corespunzatoare lecției. Modificarea și ștergerea unor lecții, respectiv exerciții stau tot în seama administratorului ca și adăugarea unor cuvinte noi în dicționar.
4.3 Arhitectura
4.3.1 Arhitectura Soft a unei aplicatii
Când vine vorba de arhitectura soft a unei aplicații, lucrurile de cele mai multe ori sunt neclare punându-se accentul pe niște informații care nu ajută foarte mult produsul soft.
Când se vorbește de arhitectură, urmatoarea perspectivă este abordată:
Arhitectura este disciplina care are rolul de a pune fundațiile unui proiect soft. Este compusă din deciziile cele mai importante – decizii care trebuiesc făcute prima oara, foarte devreme, și care trebuie să reziste pe întreaga durată de viață a proiectului. De arhitectură, de obicei, se ocupă o anumită persoană care are rolul de architect, pentru restul programatorilor considerându-se că este un concept mai greu de abordat.
Din păcate, perspectiva descrisă mai sus este parte a problemei când vine vorba de abordarea unei arhitecturi ale unei aplicații. Arhitectura nu este doar fundația. Arhitectura este un tot, un întreg. Este high level design, este low level design, abstractizarea interfețelor modulelor până la implementarea concretă de metode. Programatorii trebuie să învețe să fie arhitecți, iar arhitecții care nu scriu cod nu sunt de fapt arhitecți, sunt altceva.
De cele mai multe ori când un “arhitect” descrie ceea ce a facut este, de exemplu, de forma următoare: “ Sistemul soft construit este pe o platformă web. S-a ales Java ca limbaj de dezvoltare și Eclipse ca ustensilă de scriere de cod. Ca framework-uri s-au ales Spring, Tomcat și Hibernate. Ca bază de date s-a ales MySql și s-a decis să se folosească MVC(Model View Controller) pentru structurarea aplicației.”
Acestea nu sunt decizii arhitecturale, nici măcar pe aproape. Este ca și cum s-ar zice că arhitectura unei case este făcuta din: ciocane, cuie, lemn, ciment, fier, sârme. Când vorbim de arhitectura aplicației trebuie sa ținem cont și de cum este folosită aplicația.
Arhitectura este forma pe care sistemul o ia în urma implementarii de use case-uri astfel încat să rămână flexibilă, extensibilă și să poată fi întreținută.
Use case-urile joacă un rol foarte impotant atunci când vine vorba de arhitectură. Ele, use case-urile, sunt cele care ghidează design-ul și în final arhitectura. Tot ele ajută la definirea high level a sistemului soft.
De cele mai multe ori pattern-uri ca MVC(Model View Controller), MVP(Model View Presenter) sau MVVM(Model View View Model) sunt folosite la arhitectura unei aplicații. Aceste pattern-uri sunt bune când vine vorba de structurarea grafică( crearea de User Interface) a produsului soft. Ele nu sunt pattern-uri arhitecturale, de asemenea nu este o abordare bună când vine vorba de partiționarea high level a sistemului soft.
Atunci când un architect în construcții se uită pe planurile unei biserici, el va vedea o intrare largă, spații mai mici sau săli de conferințe în lateral. Apoi o sală mare cu o capacitate destul de semnificativă ca să găzduiască o mulțime de oameni, sala mare având în față un altar. Deci când un architect in construcții se uită la arhitectura bisercii vede o biserică.
Deci indiferent la arhitectura cărei clădiri se va uita cineva, dacă design-ul este bine făcut, va vedea în față scopul acelei arhitecturi.
Aceasta face o arhitectură bună. Nu contează că e vorba de arhitectura unei clădiri sau arhitectura unui produs soft. O arhitectură bună este legată de ideeea de folosință pentru ceea ce s-a făcut arhitectura. O arhitectură bună are nevoie de use case-uri.
Când cineva se uită la o arhitectură a unui produs soft și tot ceea ce vede este Model View Controller și varii configurații web atunci acea structură a produsului soft ascunde use case-urile acelui sistem și expune un mecanism de livrare a datelor (fie că e web, aplicație consolă, servicii windows, etc.)
Nu trebuie să se vadă, neaparat, mecanismul de livrare a unor date. Ci ceea ce trebuie să se vadă sunt use case-urile. Mai mult mecanismul de livrare a datelor nu trebuie să fie cuplat cu use case-urile.
Ceea ce e nevoie e o separare clară între use case-uri și interfața grafică (Ui – User Interface). Separarea trebuie să fie atât de clară încât cele 2 părți să poată fi lanasate la client ca 2 părți distincte. Use case-urile nu trebuie să fie deloc conștiente de mecanismul de livrare a datelor.
De fapt, deciziile în ceea ce privește interfața grafică (UI-ul), baza de date, ustensilele (tool-urile) și framework-urile să fie complet separate de use case-uri. Use case-urile trebuie să stea singure.
Mulți arhitecți plasează baza de date în centrul atenției. Nu pot să conceapă că pot face ceva fară o bază de date funcțională.
Deciziile în ceea ce privește UI-ul, baza de date și restul pot și trebuie să fie amânate. Acesta este unul din scopurile principale ale unei ahitecturi bine făcute. O arhitectură bine făcută a unui sistem soft permite amânarea deciziilor în ceea ce privește framework-urile, bazele de date, serverelor web, tool-uri de dependency injection și a altor tool-uri. O arhitectură bună ține opțiunile deschise cât mai mult posibil.
O arhitectură bună maximizeaza numărul de decizii neluate încă.
Dar cum se poate oferi suportul tehnic ca să poată să fie amânate anumite decizii? Este nevoie să se proiecteze(design) o structură care să se decupleze de acele tool-uri și framework-uri, astfel încât acele tool-uri și framework-uri să devină irelevante. Dacă arhitectura se concentrează pe use case-uri și nu pe mediul software atunci se va putea realiza decuplarea de tool-uri, baze de date și framework-uri.
De cele mai multe ori aplicațiile sunt de tipul CRUD(Create Read Update Delete) și valoarea acelor aplicații se află în UI. Dar chiar și în acest context use case-urile nu își pierd valoarea. UI-ul și use case-urile trebuie să rămână decuplate. Dacă UI-ul contează atât de mult atunci cu atât mai mult ca use case-uri să nu fie cuplate.
Poate perspectiva cea mai bună e cea legată de costuri. Dacă avem separat UI-ul de use case-uri și pot fi lansate independent. Atunci și costurile lor pot fi deduse mai bine. Mai mult dacă UI-ul costă mai mult decât use case-urile poate să fie un motiv bun de a reanaliza ceea ce trebuie făcut. Totul ca să fie sigur ca valoare business a aplicației într-un final va fi îndeplinită. Dar tehnica aceasta de separare nu se limitează doar la UI și la Use case-uri. La fel se aplică la baze de date și altele. Ideea e că fără separare nu există un mod de a zice dacă raportul de costuri între diferitele părți ale aplicației au ponderea potrivită.
Deci, dacă arhitectura produsului soft se concentrează pe use case-uri , atunci amânarea anumitor decizii poate dura mai mult, având timp chiar de răzgândire în cursul dezvoltării. Mai mult șefii de proiect pot să compare mai bine costurile asociate fiecărei părți ale sistemului și să ia deciziile cele mai optime pentru proiect.
În acest proiect punctul central ca valoare business este idea de curs online. Dacă cineva se uită peste structura acestui produs soft ar trebui sa vada lucuri ce țin de idea de cursuri online, nu de web sau baze de date, chiar dacă web-ul și bazele de date există.
Figura 4.3.1
Nu trebuie să se deducă din ce e scris mai sus că UI-ul și UX-ul(User Experience) nu contează. Dimpotriva, contează enorm de mult. Successul unui produs soft se bazează pe felul cum un utilizator folosește sau nu acea aplicație. Dar tocmai că atât de mult accent se pune pe partea de experiență ce un utilizator o are cu aplicația, ar trebui ca codul din partea de UI să fie ușor de modificat și adaptat. Cei care petrec timp în acea porțiune de cod nu trebuie să fie distrași de alte detalii business sau de configurări. Practic, separarea ajută la un mod și mai eficient de concentrare a eforturilor pe anumite părți ale aplicației atunci când este cazul, astfel încât celelalte părți să rămână fără defecte.
Web-ul este un detaliu. Nu este altceva decât un mecanism de livrare a unor date. Cum la fel sunt acum aplicațiile pentru dispozitivele mobile. Mecanismul central al unei aplicații nu ar trebui să se schimbe prin simplul fapt că a apărut o noua tehnologie de livrare a datelor. Partea bună e că o aplicație care are arhitectura bine facută va putea să se adapateze rapid la noile tendințe. Mai mult programatorii concentrâdu-și atenția strict pe acea tehnologie se pot mișca mai repede, pentru că știu că nu vor atinge cod ce privește alte părți ale produsului soft. Și acesta este un avantaj competitiv fantastic.
Concluzii:
O arhitectură nu se bazează pe tool-uri și framework-uri. O arhitectură bună permite amânarea deciziilor în ceea ce privește folosirea de framework-uri și tool-uri. O arhitectură bună maximizeaza numărul de decizii care pot să nu fie luate;
O arhitectură nu depinde de un mecanism de livrare a datelor. O arhitectură bună ascunde mecanismul de livrare a datelor;
O arhitectură bună permite o analiză mai eficientă din punct de vedere al costurilor finaniciare
4.3.2 Arhitectura fizică a aplicațiilor Java
Aproape toate pricipiile și pattern-urile ce privesc ideea de software design și de arhitectură adresează ideea de design logic. Design pattern-urile(Gang Of Four patterns), principiile SOLID(Single Responsibility Principle, Open Closed Principle, Lisktov Substitution Principle, Interfation Segregation Principle și Dependency Inversion Principle) privesc design-ul logic al unei aplicații.Sunt foarte foarte importante dar nu sunt de ajuns. Cu toate că aceste principii și pattern-uri sunt folosite, unele sisteme continuă să fie greu de întreținut, de extins și de gestionat.
Când se vorbește de design logic, de fapt urmatoarele structuri de limbaj sunt folosite: clase, operatori, metode și pachete. Indentificarea de metode într-o clasă, relațiile dintre clase țin de ideea de design logic.
Folosirea principiilor și a pattern-urilor obiect orientate este importanta. Design-ul comportamentelor complexe ale unui sistem nu este deloc ușor. Iar dacă acest design logic nu este făcut cum trebuie va avea un impact negativ în ceea ce privește creșterea și extinderea asupra întregului sistem. Deci design-ul logic este doar o piesa din ceea ce se numește software design și arhitectura. Cealaltă piesă care joaca un rol la fel de important, poate chiar mai important este design-ul fizic. Dacă nu se ia în considerare design-ul fizic al unei aplicații, atunci design-ul logic oricât de frumos ar fi s-ar putea să nu-și arate beneficiile despre care se vorbește atât de mult. Cu alte cuvinte, design-ul logic fără design fizic nu contează chiar atât de mult.
Design-ul fizic în JAVA se face prin gestionarea relațiilor si a comportamentelor fișierelor JAR. În JAVA, când se vorbește de unitatea de modularitate, este vorba de fapt de fișierul JAR.
Design-ul fizic reprezintă entitățile fizice ale sistemului software. Felul în care un sistem este “împachetat”(packaged) în JAR-uri ce vor fi livrate ține de design-ul fizic. Când se determină ce clase merg în JAR-uri ține tot de designul fizic. Gestionarea relațiilor dintre JAR-uri ține tot de designul fizic. Deci design-ul fizic joacă un rol la fel de important ca design-ul logic.
De exemplu, definirea unei interfețe care decuplează clienții acelei interfețe de clasele ce implementează acea interfață ține de design-ul logic. Alocarea interfeței respective a claselor ce o implementează în JAR-uri ține de designul fizic. Plasarea interfeței și a calselor ce o implementează în același JAR poate prezenta probleme serioase în ceea ce privește livrarea de JAR-uri. Dacă una din clase este dependentă de un sistem complex, atunci și acel sistem complex va trebui livrat, indiferent dacă clasa aceea este folosită sau nu.
Din păcate, foarte mare accent se pune pe designul logic uitându-se de design-ul fizic care joacă un rol la fel de important. Design-ul fizic este despre cum se partiționează sistemul în module. Design-ul fizic are trebă cu modularitatea, numai abordând design-ul fizic se poate vorbi de modularitatea unui sistem.
Sistemele software mari sunt mult mai complex de dezvolatat și întreținut decât sistemele mai mici. Modularitatea înseamnă spargerea sistemului mare în entități fizice mai mici, JAR-uri, făcând sistemul mai ușor de înțeles. Când se ințelege ceea ce este într-un modul și dependințele ce vin sau ies din acel modul ar fi mult mai usor de indentificat ceea ce trebuie făcut.
De exemplu, un modul cu dependințe care vin spre el este mult mai ușor de schimbat decât un modul care are foarte multe dependințe care vin spre el. Un modul care la randul lui depinde de puține module poate fi refolosit mult mai ușor, decât un modul care depinde de multe alte module. Refolosirea și întreținerea de module sunt factori foarte importanți de luat în considerare când se face design-ul modular, dependințele jucând un rol extrem de important. Pe lângă dependințe, un alt factor important este coeziunea. Un modul care face prea puțin nu este folositor altor module, deci, are o valoare minimală. Dar există și cealaltă extremă când un modul face prea multe(adică poate avea în el UI, baze de date, logică business, servicii web) va fi foarte greu de refolosit pentru că oferă mai multe funcționalități decât modulele ce l-ar referenția ar avea nevoie.
Modularitatea este piesa importantă ce lipsea atunci când se făcea arhitectura unui sistem de sus până jos.
Când se vorbește de arhitectură, există și o componentă socială a acestui concept. În proiectele de success dezvoltatorii experți care lucrează în acel proiect au o ințelegere comună a sistemului ce-l dezvolta. Toți înțeleg cum sistemul este compus din componente și cum componentele interactionează între ele. Ca să se asigure această înțelegere a sistemului de către toți dezvoltatorii, e timpul să se înțeleagă că nu mai este de ajuns să se concentreze doar pe anumite părți ale sistemului, ci pe tot acest sistem, inclusiv părțile de modularitate.
Arhitectura înseamnă tot:
Figura 4.3.2.
Cu cât un sistem este mai flexibil, cu atât acesta poate să se adapteze și să evolueze când trebuie.
Aplicația curentă are următoarea structură:
Fig. 4.3.3. Structura aplicației
În figura de mai sus se observă mai multe module. Mai jos se află detaliată descrierea lor:
UI – este layer-ul ce ține interfața grafică. În cazul de față, este locul unde vor fi definite paginile web. Framework-ul JSP(Java Server Pages) aici își are locul. Acest layer nu are cunoștiințe de baze de date, sau de domeniul business. Rolul acestui layer este să prezinte datele într-un anumit format, respectiv să trimită niște date.
Acest layer nu comunică direct cu logica business. Logica business este complet decuplată de mecanismul de livrare a datelor.
Serviciile Aplicației – acesta este layerul ce are rolul de a comunica cu modelul business. A nu se confunda denumirea de “ServiciiileAplicațiiei” cu ideea de servicii web,care sunt și ele la randul lor un mecanism de livrare a datelor, nimic mai mult.
Acest layer este o fațadă. Logica business poate fi destul de complexă de aceea el poate masca toată complexitatea cu o simplă apelare de metodă, făcând în spate toată orchestrarea de funcționalități. De asemnea, tot acest layer are rolul de a creea structuri de date, numite câteodata ViewMode-le, pentru UI. UI-ul nu trebuie să știe de toate detaliile din domenul business, de aceea acest layer pregătește datele de care UI-ul are nevoie într-un format pe care UI-ul va putea să-l interpreteze dar și în așa fel încât modelul business să nu fie afectat, sau UI-ul să nu fie afectat dacă modelul business se schimbă în vreun fel.
Logica de business – acest layer are rolul de a defini modelul business al aplicației. Acest layer va avea nevoie de date pentru a-și face treaba. Dar nu se va ocupa el de a le prelua direct din sursa de date (fie ca e baza de date, fișiere xml etc). Aici se află interfețele ce definesc tipul de date ce se iau din sursa de date. Dar aici nu sunt conținute clasele ce implementează acest mecanism. Clasele se află in layer-ul Repository.
Repository – acest layer se ocupă de comunicarea cu sursa bazei de date. Aici se va afla codul ce ține de JDBC, Hibernate sau alte tehnologii ce comunică cu baza de date- dacă datele sunt ținute în bazele de date. Inițial, datele din pagini erau servite din fișiere XML. Pentru a vedea aplicația funcțională nu era neapărat nevoie de o bază de date. După aceea apărând necesitatea unei baze de date, aici a fost locul unde s-a modificat logica de preluare a datelor. Celelalte layere neștiind de faptul că mecanismul de preluare a datelor a fost schimbat în vreun fel.
Se poate zice că toată această logică se putea pune într-un singur modul. Mai mult, fiecare pagina web să conțină tot codul de care are nevoie pentru a exista. Și anume cod: de business model, de baza de date, de UI, de servicii web:
Figura 4.3.4. Tot codul la un loc
Prin simplul fapt că se poate face așa ceva nu înseamnă că și trebuie.
Un lucru care caracterizează sistemele soft este ideea de complexitate. Complexitatea există și ea trebuie înfruntată. Și modul de a înfrunta aceată complexitate este prin modularitate.
Mai jos se află o figură ce ilustrează un sistem cu un design de clase destul de complex:
Figura 4.3.5. Sistem cu o structură de clase complexă
Când o schimbare apare într-o singură clasă, a se vedea cercul roșu, este greu de observat implicațiile ce pot rezulta din acea modificare:
Figura 4.3.6. Intervine schimbarea în structura de clase complexă
Deci o înțelegere a impactului deciziei în ceea ce privește acea clasă este destul de dificil. Trebuie înțeleasă toată acea structură de clase pentru a avea siguranța că nu se va strica ceva.
Dacă aplicația ar fi partiționată în module, atunci lucrurile ar fi mai clare:
Figura 4.3.7. Partiționarea în module
Acum nu trebuie decât investigat impactul ce îl are acea clasă în cadrul modului. Și eventual să se vadă în ce fel un alt modul e afectat. Dar deja când există această partiționare, frica de a schimba ceva dispare. Practic dezvoltatorului îi va fi mult mai ușor să gândescă strategia modificării ce o are de făcut. Nivelul de detaliu se schimbă, e mult mai simplu:
Figura 4.3.8. Schimbarea este izolată
Exemplul ilustrat mai sus este unul simplu, dar arată cât de importantă este modularitatea într-un sistem soft. Modularitatea face ca întregul sistem soft să fie înțeles mai ușor. Face întreținerea sistemului soft mai ușoară. Mai mult, modulele pot fi refolosite. Cu cât sistemul soft crește în complexitate și mărime, este imperios necesar să se ia în considerare modulele.
În această lucrare de licența sistemul soft este unul simplu. Clar nu are nevoie de foarte multe module. Dar și în această simplitate a lui partiționarea modulară și-a arătat părțile benefice când a trebuit rescris codul pentru a se lua informații din baza de date și nu din fișiere XML.
4.4 Diagrama claselor
Clasa UML modelează componentele (entitățile) de interes ale unui sistem. Clasa are instanțe, sau realizări. Aceste instanțe sunt obiectele clasei. Prin conceptul de clasă se descriu structura și comportarea obiectelor clasei. Structura conține atributele fiecărui obiect din clasă. Comportarea include operațiunile ce pot fi executate (efectuate) pe (asupra) o instanță specifică de obiect.
Notația grafică pentru clasa UML:
Nume de clasă
Atribute
Operațiuni
Stereotipuri: șirul de caractere așezat între ghilimele (« ») în partea de sus este un stereotip. Un stereotip reprezintă un mod de a extinde semantica unui element de modelare, cum este o clasă. În cazul de față, stereotipul «persistent» identifică clasa Lesson ca fiind o clasă persistentă. Clasa persistentă este acea clasă pentru care instanțele sale persistă în memorie după ce procesul care a creat aceste instanțe a luat sfârșit.
În modelarea pentru bazele de date, stereotipul «persistent» indică faptul că o clasă trebuie să fie reprezentată (realizată, “mapped”) printr-o reprezentare corespunzătoare a bazei de date în timpul implementării. O clasă fără stereotipul «persistent» reprezintă un obiect tranzitoriu, care nu persistă în memorie.
Atribute: Sintaxa de specificare a atributelor:
[«stereotype»] [visibility] [/] attributeName [multiplicity] : [type] [=initialValue], în care:
«stereotype» este un stereotip UML, definit de utilizator, pentru a îmbogății semantica (înțelesul!) unei definiții de atribut;
visibility folosește simbolurile:
+ pentru vizibilitate publică (orice clasă poate avea acces la atribut);
# pentru vizibilitate protejată (numai clasa respectivă și succesorii săi pot avea acces la atribut);
pentru vizibilitate privată (numai clasa respectivă poate avea acces la atribut);
/ pentru a reprezenta un atribut „derivat”;
attributeName reprezintă numele atributului;
multiplicity indică dacă atributul este multi-valoare;
type este un nume de clasă, sau un tip de date, care definește tipul valorii ce se memorează în atribut
initialValue indică o valoare “lipsă” (“default”) care trebuie atribuită atributului.
Operațiuni: Sintaxa “prin lipsă” (“default”) pentru specificarea semnăturii unei metode este:
[«stereotype»] [visibility] methodName ([parameterList]) : [returnType], în care:
«stereotype» este un stereotip UML sau definit de utilizator pentru a îmbogății semantica (înțelesul) unei operațiuni;
visibility folosește simbolurile:
+ pentru vizibilit ate publică (orice clasă poate executa metoda);
# pentru vizibilizate protejată (numai clasa și subclasele sale pot executa metoda);
pentru vizibilitate privată (numai clasa poate executa metoda);
methodName reprezintă numele metodei;
parameterList este o listă de atribute, sau de perechi de tipuri, separate prin virgule, pentru a indica parametrii formali ai metodei;
returnType este numele clasei sau tipul de date care indică tipul valorii returnate (întoarse) de o funcție.
Având in vedere aceste caracteristici, în figura 4.4.1 este prezentată diagrama claselor pentru aplicația prezentată.
Figura 4.4.1 Diagrama claselor
4.5 Use Case-uri
În 1992 Ivar Jacobson a scris cartea “Object Oriented Software Engineering: A Use Case Driven Approach”. Acolo se află idea în care o concentrare pe mecanismul de livrare este o problemă. Iar soluția propusă de el este să se înțeleagă cum utilizatorii interacționează cu sistemul, într-un mod ce nu implica mecanisme de livrare a datelor(web, aplicații pe mobile, windows services etc).
Cu alte cuvinte, se descrie cum un utilizator interacționează cu produsul soft fără să se folosească termeni ce țin de tehnologii web ca: “click”,”link”, “button”, “web page”. Ivar Jacobson a numit aceste descrieri despre cum un utilizator va interacționa cu sistemul ca use case-uri. De aceea și subtitlul cărții sale “A Use Case Driven Approach”.
Deci, un use case nu este altceva decât o descriere formala despre cum un utilizator interaționează cu sistemul astfel încat să-și îndeplinească obiectivul dorit.
De exemplu, dacă scopul este să se creeze o lecție într-un sistem ce se ocupă de cursuri online atunci un asemenea use case va avea urmatoarea formă:
Creare Lecție
Administratorul creează o lecție. Lecția având un titlu, descriere și conținut;
Sistemul validează informațiile introduse;
Sistemul va crea lecția și va determina identificatorul(id-ul) acesteia;
Sistemul va da utilizatorului identificatorul lecției.
Acesta este use case-ul. După cum se vede use case-ul nu conține mențiuni către ecrane, po-up-uri, butoane sau orice altceva legat de idea de web. De asemenea răspunsul use case-ului, id-ul lecției, poate fi complet mascat de către mecanismul de livrare a datelor, astfel încât utilizatorul uman să nu îl vadă. Acesta este un detaliu important, deoarece ca să se creeze o arhitectura care nu este cuplată cu anumite detalii, use case-urile trebuie să fie independente de orice altceva în descrierea lor.
Use case-ul seamănă mai mult cu o descriere, mai generică, a unui anumit algoritm legat de manipularea unor date de intrare și producerea unor date de ieșire. Asta înseamnă că se poate crea un obiect ce va ști cum să implementeze acest use case.
De obicei în implementarea unui use case apar mai multe detalii care fac ca use case-ul să se complice un pic. De exemplu ce ar trebui să se întâmple când validarea datelor introduse pentru noua lecție este cu probleme? Excepțiile se mai numesc și extensii. Mai jos este descris un exemplu:
Extensie
Dacă identificatorul lecției nu există, creează o noua lecție
Dacă identificatorul lecției există, atunci informațiile(titlul, descrierea, textul lecției) trebuiesc înlocuite cu ce s-a introdus.
Cu cât se vor crea mai multe use case-uri se va vedea că vor apărea obiecte ce să implementeze acele use case-uri.
Din păcate în toți acești ani s-a abuzat destul de mult de această noțiune de use case-uri. De cele mai multe ori rămânând doar un proces formal de cum să arate un use case și cum să se introduca date in use case. Moduri care adeseori erau destul de complexe , greu de creat și de urmărit. Timpul petrecut în a se crea o serie de use case-uri crescând considerabil.
Deci o arhitectură bazată pe use case-uri va izola mecanismul de livrare a datelor, baza de date de restul aplicației.
Adeseori modul acesta de a organiza o aplicație pare greoi și stufos. Dar atunci când fiecare părticică are locul ei in sistem va fi mult mai ușor să se întrețină acel sistem.
Deci un use case e ca un fel de “contract” dintre cei care folosesc sistemul(stakeholders) și comportamentul sistemului. Use case-urie descriu comportamentul sistemului sub anumite condiții făcute de unul din stackeholderi, care se mai numește și primary actor. Acest primary actor inițiază interacțiunea cu sistemul ca să îndeplinească un anumit scop. Sistemul va răspunde, protejând interesele tuturor stakeholder-ilor. Diferite scenarii pot reieși pentru îndeplinirea unui scop. Use case-ul înglobează în ele aceste scenarii.
Use case-urile de obicei sunt sub formă text, dar pot fi scrise folosind flow chart-uri, diagrame de secvență sau chiar limbaje de programare. În condiții normale ele servesc ele ajută la comunicarea unor informații dintre persoane, de aceea de obicei o descriere textuală a unui use case este abordarea cea mai potrivită.
Use case-ul, ca și formă de scriere, poate fi folosit pentru a stimula discuția dintr-o echipă atunci când se vorbește de un sistem nou. După, aceea echipă poate folosi acel use case ca să documenteze cerințele (requirements).
Use case-urile pot fi folosite în mai multe situații pentru a descrie:
Procesul de lucru al business-ului;
Pentru a concentra discuția spre viitoarele cerințe ale sistemului, dar nu vor lua locul cerințelor sistemului (requirements);
Cerințele funcționale ale unui sistem;
Fiecare situație cere un stil de a scrie un use case diferit.
Când se scriu use case-urile pentru a servi ca cerințe ale unui sistem, următoarele 2 lucruri trebuiesc luate în considerare:
Ele sunt cerințe. Nu trebuiesc convertite într-o altă formă. Dacă sunt scrise cum trebuie, ele vor descrie în detaliu ceea ce sistemul va face;
Ele nu vor fi toate cerințele unui sistem soft. Ele nu descriu în detaliu interfețele grafice, formatul de date. Ele constituie doar o parte, poate un sfert, din toate cerințele ce trebuiesc îndeplinite;
De asemenea use case-urile ajută la conectarea informațiilor ale diferitelor părți ale cerințelor.
În figura 4.5.1 avem ilustrată diagrama Use Case pentru proiectul prezentat. Sunt analizate doua cazuri. În partea stângă este perspectiva unui utilizator oarecare, iar în partea dreaptă cea a administratorului.
Figura 4.5.1 Diagrama Use Case a proiectului
5.Prezentarea aplicației
Pentru rularea aplicației este necesar ca serverul de Tomcat să fie pornit. Acest lucru se poate face din executarea comenzii startup în cmd din tomcat/bin sau este suficient să rulăm programul din eclipse după cum urmează în Figura 5.1:
Figura 5.1
Programul rulează în Tomcat 7 la localhost:8080, setărie serverului fiind stabilite în momentul începerii scrierii programului web în eclipse.
După efectuarea pasului de mai sus se deschide o noua fereastră în eclipse cu conținutul paginii Index.jsp (Figura 5.2), url-ul ei fiind http://localhost:8080/Curs.WebUI/Index.jsp. Această pagină este constituită din cod Html și conține informații generale despre limba engleza, dar și câteva despre aplicație.Din meniu se fac redirectările către celelalte pagini: Lecții, Exerciții, Dicționar și Contact.
Figura 5.2
Daca dăm click pe tab-ul Lectii suntem redirectați către o pagină ce conține sumarul lecțiilor existente (Figura 5.3). Fiecare lecție conține o imagine reprezentativă cu titlul acesteia și o scurtă descriere a datelor conținute.
Figura 5.3
Display-ul acestei pagini se face prin metoda GetDisplay(), aplicată clasei LessonSummaryDisplayLogic.jsp (Figura 5.4), clasă ce o putem vedea în Figura 5.5
Figura 5.4
Figura 5.5
După ce selectăm lecția pe care dorim să o vizualizăm ni se deschide o nouă pagină ce conține lecția cu id-ul selectat, exemplu în Figura 5.6. Aceași structură o au și exercițiile, singura diferență fiind ca acestea nu mai conțin descrierea datelor din fiecare capitol în pagina de selectare a exercițiului.
Figura 5.6
În Figura 5.8 avem ilustrat dicționarul aplicației. Putem alege tipul dicționarului, englez-român sau român-englez cu ajutorul meniului drop-down.
Pagina Contact.jsp (Figura 5.8) conține un formular pentru sugestii si câteva date despre autor.
Figura 5.8
Pentru a modifica anumite date, precum adăugarea, ștergerea sau modificarea lecțiilor, dar și adăugarea unor noi cuvinte în dicționar este necesară autentificarea ca administrator. Butonul de autentificare se află în partea stânga-sus a paginii web, iar în urma apăsării acestuia suntem redirectați la pagina de autentificare (Figura 5.9).
În momentul în care suntem autentificați meniulul aplicației se schimbă, permițandu-I acestuia să modifice datele dorite.
În continuare avem prezentat un exemplu în care se vor demonstra atribuțiile adminstratorului (Figura 5.10 – Figura 5.14).
Figura 5.9
Figura 5.10 – Adaugarea unei lecții noi
Figura 5.11 – Lecția nouă a fost adăugată cu succes
Figura 5.12 – Modificarea unei lecții
Observam ca am modificat titlul lecției.Iar dupa apasarea butonului Modifica Lectie ar trebui sa apara fereastra cu sumarul lecțiilor și titlul modificat la lecția aleasă.
Figura 5.13 – Lecția modificată
Figura 5.14 – Adăugarea unui cuvânt în baza de date si mesajul apărut după această operație
6.Concluzii
În ziua de azi, în domeniul despre care vorbim, foarte multă lume pune accentul pe tehnologii și uită aspectul cel mai important: scopul pentru care muncim, la ce vrem să ajungem. Evident, aceste tehnologii cu care lucrăm sunt foarte importante, dar asta nu înseamnă că trebuie sa ne împiedice faptul că nu am mai lucrat cu ele sau că nu știm ce alegeri să facem în această privință. O arhitectura bună stă la baza tuturor proiectelor, fie că este vorba de aplicația prezentată sau construcția unei clădiri. O arhitectură bună ne permite să amânăm anumite decizii ce trebuiesc luate în cadrul proiectului nostru.
Pe acest lucru se bazează și acest proiect. De exemplu, la început era vorba de un simplu proiect ce rula în consolă, doar pentru a se vedea că lucrurile din spate funcționează.Baza de date nu a existat nici ea, datele fiind preluate din fișiere xml.Pe parcurs insă, am observant că o bază de date este mai potrivită pentru acest proiect, așa că a fost implementată, modificările apărute nefiind majore. Astfel, structura aplicației m-a ajutat enorm atunci cănd apăreau schimbări în planul aplicației.
În concluzie, cu ajutorul tehnologiilor prezentate, a unor use case-uri bine puse la punct și a unei bune arhitecturi aplicația a luat forma finală. S-au îndeplinit astfel și obiectivele propuse, cursul de limba engleză luând forma dorită.
Bibliografie
Beginning JSP , JSF and Tomcat Web Development From Novice to Professional – Giulio Zambon , Michael Sekle
The priciples of OOD, http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod – Robert C. Martin
Clean Architecture,http://vimeo.com/43612849 – Robert C. Martin
Java Application Architecture: Modularity Patterns with Examples Using OSGi – Kirk Knoernschild
Clean Code:Function, http://vimeo.com/12643301 – Robert C. Martin
Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin
W3W Html, http://www.w3schools.com/html/DEFAULT.asp
W3W Java Script, http://www.w3schools.com/js/default.asp
W3W CSS, http://www.w3schools.com/css/default.asp
http://www.tutorialspoint.com/jdbc/jdbc_tutorial.pdf
Curs practic de Java, Cristian Frasinaru
CURS DE PEDAGOGIE – Conf. univ. dr. Adriana NICU
http://andrei.clubcisco.ro/cursuri/f/fsym/4ioc/labs/Lab%205%20DOM%20vs%20SAX.pdf
http://www.w3schools.com/dom/dom_parser.asp
http://interfetewebas.blogspot.ro/2008/11/dom-vs-sax.html
MySQL Workbench, http://www.mysql.com/products/workbench
MySQL Workbench, http://docs.oracle.com/cd/E17952_01/workbench-en/workbench-en.pdf
Prof. dr. ing. Mircea Petrescu, Diagrame de clase conceptuale în limbajul de modelare unificat (UML)
Bibliografie
Beginning JSP , JSF and Tomcat Web Development From Novice to Professional – Giulio Zambon , Michael Sekle
The priciples of OOD, http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod – Robert C. Martin
Clean Architecture,http://vimeo.com/43612849 – Robert C. Martin
Java Application Architecture: Modularity Patterns with Examples Using OSGi – Kirk Knoernschild
Clean Code:Function, http://vimeo.com/12643301 – Robert C. Martin
Clean Code: A Handbook of Agile Software Craftsmanship – Robert C. Martin
W3W Html, http://www.w3schools.com/html/DEFAULT.asp
W3W Java Script, http://www.w3schools.com/js/default.asp
W3W CSS, http://www.w3schools.com/css/default.asp
http://www.tutorialspoint.com/jdbc/jdbc_tutorial.pdf
Curs practic de Java, Cristian Frasinaru
CURS DE PEDAGOGIE – Conf. univ. dr. Adriana NICU
http://andrei.clubcisco.ro/cursuri/f/fsym/4ioc/labs/Lab%205%20DOM%20vs%20SAX.pdf
http://www.w3schools.com/dom/dom_parser.asp
http://interfetewebas.blogspot.ro/2008/11/dom-vs-sax.html
MySQL Workbench, http://www.mysql.com/products/workbench
MySQL Workbench, http://docs.oracle.com/cd/E17952_01/workbench-en/workbench-en.pdf
Prof. dr. ing. Mircea Petrescu, Diagrame de clase conceptuale în limbajul de modelare unificat (UML)
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: Sistem Suport Pentru Instruire In Domeniul Stiintelor Umaniste (ID: 163575)
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.