Mentenanta,flexibilitate Si Testabilitatea Aplicatiilor Arhitectura Mvc

Mentenanta,flexibilitate si testabilitatea aplicatiilor

Arhitectura MVC

Cuprins

Capitolul 1. Introducere

1.1. Rezumat

1.2. Obiective. Scopul lucrării

Capitolul 2. Elemente de grafică sub Windows

2.1. Inițializare

2.2. Utilizare

2.2.1. DrawLine

2.2.2. DrawEllipse

2.2.3. DrawRectangle

2.2.4. DrawArc

Capitloul 3. Construirea fractalilor

3.1. Modelul de fractal propus

3.1.1. Numărul de puncte

3.1.2. Dimensiunile

3.1.3. Punctul central

3.1.4. Rotația

3.2. Fractal Point

3.2.1. Mutația de dispariție a unei ramuri

3.2.2. Mutația de apariție a unei ramuri

3.2.3. Reprezentarea grafică a punctelor de interes

3.2.4 Variabila suport pentru ȋncheierea evoluției

3.2.5. Reductorul

3.3. Fractali asimetrici unghiulari

Capitolul 4. Utilizarea aplicației. Rezultate

4.1. Structura aplicației

4.2 Formularul principal

4.3. Setări RTS

4.4. Setări Orbite

4.5. Setări de mișcare

4.6. Concluzii

Bibliografie

Capitolul 1. Introducere

1.1. Rezumat

Lucrarea se ȋmparte pe 5 capitole.

Capitolul 1 prezintă conceptele generale introduse, obiectivele propuse și elemntele de algoritmică necesare parcurgerii acestei lucrări.

Capitolul 2 este destinat prezentării modului de utilizare a graficii sub Windows, pe baza obiectelor din clasa Graphics și metodelor acestuia. Tot ȋn acest capitol utilizatorii se pot familiariza cu principalele tehnici și metode ale acestui gen de programare.

Capitolul 3 prezintă modelul de fractal introdus ȋn această lucrare, parametrizarea acestuia și intervalele de valori disponibile variabilelor constructive. Sunt prezentați o serie de fractali derivați din modelul de bază și se construiește o legătură pas cu pas ȋntre definirea variabilelor și corespondentul lor teoretic.

Capitolul 4. ȋncheie lucrarea prin prezentarea funcționalității aplicației practice și opțiunile accesibile utilizatorilor. Tot ȋn acest capitol se prezintă construcția aplicației din punct de vedere al programării orientate pe obiecte și mediului vizual de programare dezvoltând fiecare componentă a proiectului pe baza metodelor principale și a variabilelor membru.

1.2. Obiective. Scopul lucrării

Lucrarea de față propune construirea unei arhitecturi care sa permita mentenata, testabilitatea si flexibilitatea aplicatiilor. Obiectivul principal este construirea unei aplicației prin care se vrea gestionare resurselor financiare si este destinat persoanelor fizice cat si persoanelor juridice. Această aplicație rezova problema gestionarii bugetului unei familii, persone sau institutie.

La nivelul lucrării, obiectivul secundar se bazează pe familiarizarea cititorilor cu modul de

proiectare a unei aplicatii web utilizand o arhitectura pe mai multe nivele ca sa ne permita fexibilitate si nu in ultimul rand testabilitate.

Cunoștințele necesare parcurgerii acestei lucrări se referă ȋn special la noțiuni elementare despre programarea orientate obiect O.O.P., O.O.D. (pentru a ȋnțelege structura proiectului și programarea pe evenimente),principiile S.O.L.I.D.,programare C# , programare JavaScript si AngularJS, teste automate, baze de date S.Q.L,Entity Framework,HTML si CSS.

1.3. Introducere in dezvoltarea aplicatiilor web

Pentru a putea dezvolta o aplicatie web avem nevoie in primul rand de cateva notiuni introductive care ne vor ajuta la intelegerea lucrarii si la dezvoltarea propriu-zisa a aplicatiei. Atunci cand vorbim despre o aplicatie web trebuie sa ne gandim diferit fata de aplicatiile Windows pentru ca sunt concepte diferite.

Fig.1.1

1.3.1. Serverul

In primul rand trebuie sa vorbim despre conceptual de server care nu reprezinta altceva decat un calculator care stocheaza fisierele aplicatiei noastre si resursele acesteia si printr-un protocol de comnuicare numit H.T.T.P. acum si H.T.T.P.S comunica cu un browser primind si trimitand informatii.Comunicarea se face printr-o cere din partea clientului numita request care este procesata de serverul unde este gestionata aplicatia si se returneaza clientului o pagina HTML.

Acest server poate gestiona si o conexiune la baza de date sau cu alte servere aflate in retea sau internet, unde se pot stoca informatii care vream sa se persiste pe o perioada mai lunga deoarece dupa incheierea cererii datele nu se persista doar daca vream lucrul acesta si se poate realiza prin sesiuni sau salvare in baza de date.Despre Arhitectura server vom discuta in capitolele urmatoare.

1.3.2 Clientul

In al doilea rand trebuie sa vorbim despre client care poate fi un browser sau un seviciu care acceseaza serverul pentru anumite informatii.Clientul lanseaza cererea si primeste raspuns de la server pe care il afiseaza.

1.3. 3 HTML si CSS

Unul din primele elemente fundamentale ale WWW ( World Wide Web ) este HTML ( Hypertext Markup Language ), care descrie formatul primar in care documentele sint distribuite si vazute pe Web. Limbajul HTML consta in niste taguri care sunt interpretate de aplicatia client si desenate intr-un format destul de robust.

Pentru a crea o pagina HTML avem nevoie de un editor text, adaugam un fisier nou si il salvam cu extensia HTML.Structura de baza a unei pagini web se poate vedea in figura Fig. 1.1

Fig. 1.1 Structura pagina HTML

Rezultatul acestui cod este o pagina alba afisand textul “Continut”.HTML –ul este compus din taguri si attribute.In cele ce urmeaza o sa afisam un dreptunghi cu laturile de culoare rosie, cu inaltimea de 100px si latimea de 200px.

Pentru a afisa dreptunghiul din figura 11 a fost nevoie sa adaugam un tag special numit div <div> in loc de textul “Continut” si cu ajutorul atributului de syle am setat inaltimea, latimea si culoarea marginii.

Fig.

Atributul style este un atribut care ne permite sa scrie CSS care vine de la Cascading Style Sheets care este un limbaj foaie de stil folosită pentru a descrie aspectul și formatarea unui document scris într-un limbaj de markup (HTML) si se poate salva in fisiere cu extensia .css incluzandu-le ulterior in HTML.CSS-ul

Nu putem vorbi de CSS fara sa amintim doi cei mai important selectori:

#ID – selecteaza elementul HTML unde este gasit textul specificat si se pot aplica formatari pe acest element.Identificatorul trebuie sa fie unic in toata pagina.Pentru a specifica un id se pune la inceput caracterul ‘#’

.CLASS – selecteaza toate elementele unde este gasita clasa specificata si aplica formatarea specificata.Pentru a specifica selectorul de clasa se foloseste semnul de punctuatie ‘.’.

Pot fi si alti selectori ca si selector dupa tag, sau atribut.

Diferenta dintre cele doua selectoare este evidenta, o clasa se poate folosi pe mai multe elemente HTML in schimb ce un id se poate folosi doar pe un singur element.

Fig. 11

In figura anterioara avem definit un selector id pentru rectangle si o clasa rectangle care pot fi folosite in pagina HTML cu ajutorul atributelor id si class.

1.3.4 JavaScript

JavaScript este un limbaj de  programare care face posibil ca paginile web sa fie mai interactive. Este mai  des recunoscut ca facand parte din categoria "Scripting Languages".

Cu ajutorul limbajului javascript putem manipula structura HML, putem crea animatii, ascunde elemente, aplela serverul prin requesturi ajax.La ora actual sunt servere ca NODEJS care folosesc limbajul javascript ca si limbaj de server.

Fig. 11

Putem adauga cod javascript in pagini HTML dupa cum se poate vedea in figura 11, insa exista si modalitatea de a include fisiere cu extensia .js.

Exista foarte multe framework-uri javascript dintre care amintim JQuery,AngularJS si NockOutjs care ne ajuta sa getionam resursele javascript intr-o Arhitectura modulara care este mai usor de intretinut si testat.

Rezultatul codului din figura 11 il putem vedea in figura urmatoare unde avem un dreptughi si textul afisat cu ajutorul javascript.

Fig. 11

Capitolul 2. Mentenata aplicatiilor

2.1. Mentenanta aplicatiilor

Întreținerea software în ingineria software este modificarea unui produs software de la livrare pentru a corecta greșelile, pentru a îmbunătăți performanța sau adaugarea de functionalitate noua.

O percepție comună cu întreținerea este că pur și simplu implică defecte de fixare. Cu toate acestea, un studiu a indicat faptul că peste 80% din efortul de întreținere este utilizat pentru acțiuni non-corective. Această percepție este perpetuată de către utilizatori care depun problemă raportează că, în realitate, sunt imbunatatiri de funcționalitate a sistemului. [Necesită citare] Mai multe studii recente pun proporția-bug fixare aproape de 21%.

2.2. Importanța de întreținere software

Problemele de întreținere software sunt atât manageriale cat și tehnice.

Aspectele de management sunt: ​​alinierea cu prioritățile clientului, angajatii care se ocupa de întreținere, estimarea costurilor. Probleme tehnice cheie sunt: ​​înțelegere limitată, analiza de impact, testarea.

Întreținerea software este o activitate foarte vasta si complicata, care include corectare a erorilor, îmbunătățiri de capabilități, ștergerea capacităților învechite și optimizare. Deoarece schimbarea este inevitabilă, mecanismele trebuie să fie dezvoltate pentru evaluarea, controlul și pentru a suporta modificări.

Deci orice lucrare care implica rescrierea codului după ce este în funcțiune este considerat a fi lucrare de întreținere. Scopul intretinerii este de a păstra valoarea aplicatiei la functionalitate normala si la cerintele de tehnologie. Valoarea poate fi îmbunătățită si prin folosirea tehnologiei de actualitate. Întreținere poate întindepe perioade lungi de 10 de ani, în timp ce dezvoltarea ar putea fi de 1-2 ani.

Pentru a preveni pierderea de timp prin introducerea de erori la modificarea unei aplicatii, trebuie sa respectam cateva principii model de baza in dezvoltarea aplicatiei cat si ulterior la intretinere.

2.3. Principii de design in dezvoltarea aplicatiilor.

Pentru ca o aplicatie sa fie usor de intretinut, sa fie flexibila da modificari ulterioare, sa fie testabila, trebuiesc urmate cateva principia de design care ne vor ajuta la scrierea unui cod de calitate care in final ne va aduce satisfactiile dorite.

Cateva principii:

DRY – don’t repet yourself – nu perminte duplicare de cod in aplicatie, daca avem cod care se repeata in mai multe locuri in aplicatie cu siguranta este candidat pentru rescriere si trebuiesc scoase in metode separate care sa fie apelate in mai multe locuri.Acest principiu este important deoarece ne ajuta la mentenata codului, daca ulterior avem de modificat ceva in zona care anterior era duplicata efortul pentru modificarea codului in toate modulele este costisitor de timp si pericolul este foarte mare sa introducem erori nedorite.

KISS – keep it simple and stupid – pastreaza codul cat mai smplu, o metoda ar trebui sa faca un singur lucru si doar atat, nu sunt recomandate metodele care fac de toate, selecteaza userul, trimite mail. Principiul seamana cu principiul “single responsibility” din cele 5 principii solid care le vom expune in cele ce urmeaza.

Y.A.G.N.I – you ain’t gonna need it – principiul ne specifica sa nu scriem metode care nu sunt necesare, sau care credem noi ca o sa fie necesare la cineva in viitor, atunci cand este nevoie de o metoda atunci se va scrie.

2.4. Scurta prezentare principii SOLID

În programare, SOLID (responsabilitate unică, deschis-închis, substituire Liskov, Interfata segregare și inversara dependentelor) este un acronym introdus de Pene Michael pentru "primele cinci principii" numite de Robert C. Martin la începutul anilor 2000 care reprezintă cinci principii de bază de programare și proiectare orientate-obiect. Principiile, atunci când sunt aplicate împreună, intenționează să facă mult mai probabil ca un programatordificarea codului in toate modulele este costisitor de timp si pericolul este foarte mare sa introducem erori nedorite.

KISS – keep it simple and stupid – pastreaza codul cat mai smplu, o metoda ar trebui sa faca un singur lucru si doar atat, nu sunt recomandate metodele care fac de toate, selecteaza userul, trimite mail. Principiul seamana cu principiul “single responsibility” din cele 5 principii solid care le vom expune in cele ce urmeaza.

Y.A.G.N.I – you ain’t gonna need it – principiul ne specifica sa nu scriem metode care nu sunt necesare, sau care credem noi ca o sa fie necesare la cineva in viitor, atunci cand este nevoie de o metoda atunci se va scrie.

2.4. Scurta prezentare principii SOLID

În programare, SOLID (responsabilitate unică, deschis-închis, substituire Liskov, Interfata segregare și inversara dependentelor) este un acronym introdus de Pene Michael pentru "primele cinci principii" numite de Robert C. Martin la începutul anilor 2000 care reprezintă cinci principii de bază de programare și proiectare orientate-obiect. Principiile, atunci când sunt aplicate împreună, intenționează să facă mult mai probabil ca un programator va crea un sistem care este usor de intretinut si extinde în timp.Principiile SOLID sunt linii directoare care pot fi aplicate în timp ce lucrează la software pentru a elimina codul defectuos prin provocarea programatorilor pentru a repara codul sursă al software-ului până când este atât de citit și extensibil. Este parte dintr-o strategie generală de programare agil și adaptiv.

Acronimul S vine de la (Single responsibility principle) responsabilitate unica SRP si ne spune ca o clasa ar trebui sa aiba o singura responsabilitate si daca exista o singura posibilitate de schimbare ar trebui separate in concept diferite.

O OCP (Open/closed principle) deschis/ inchis ne spune ca entitatile soft ar trebui sa fie deschise pentru extindere dar sa fie inchise pentru modificarea codului de baza.

L LSP (Liskov substitution principle) ne sfatuieste ca obiectele intr-un program trebuie sa poata fi inlocuite de typuri din care deriva fara a afecta functionalitatea programului.

I ISP (Interface segregation principle). ne sunt recomnadate interfete specifice de dimensiuni reduse decat cele generale de dimesiuni mari.Logica este ca sa oferi clientului ceea ce are nevoie si sa nu il obligi sa implementeze lucruri pe care nu le foloseste.

D DIP (Dependency inversion principle) ne indruma sa nu avem obiecte care depind de clase concrete ci sa depinda de abstractizare.Acest principiu se realizeaza cu ajutorul interfetelor.

Capitolul 3. Flexibilitatea aplicatiilor

3.1. Arhitectura Three-tier

O aplicatie creata pe un singur nivel poate deveni in timp foarte greu de intretinut, testabilitatea fiind foarte greu de facut, nu se recomanda gruparea codului intr-un singur nivel.

Fig.11

In timp s-a introdus ca layer separat accesul la bazele de date, motivul a fost pentru a putea refolosi accesul la bazele de date pe mai multe interfete de utilizator, deci flexibilitate, reutilizare si testabilitate.

Arhitectura 3-tier a aparut ca o imbunatatire a arhitecturii pe doua nivele care s-a dovedit ineficienta in timp pentru aplicatii mai mari. Prin introducerea unui nivel intermediar intre aplicatia client si baza de date se poate spori performanta, imbunatatind disponibilitatea aplicatiei, ea devenind mai robusta.

Acest nivel de mijloc contine elemente de logica a aplicatiei, putand fiind constituit dintr-un server de aplicatie ( application server).

Un model de tip Three-tier conține următoarele nivele :

Nivelul de prezentare (nivelul client) – acesta reprezintă nivelul superior al aplicației. Nivelul de prezentare afișează informații legate de servicii cum ar fi căutarea și achiziționarea de mărfuri, conținutul unui coș de cumpărături online sau afisarea unei harti. Acest nivel comunică prin trimiterea de rezultate către nivelul browser/client, rezultate care sunt afisate utilizatorului.

Nivelul logic (nivelul de mijloc) – acesta este extras din nivelul de prezentare și controlează funcționalitatea aplicației prin realizarea de procesări detaliate.

Nivelul de stocare a datelor – acesta constă în serverele de baze de date. Informația este stocată și extrasă de aici. Acest nivel menține datele neutre și independente de serverul de aplicație și de regulile logice. Oferind datelor un nivel separat, se obțin îmbunătățiri în performanță, testabilitate și scalabilitate.

3.2. Implementarea nivelului de prezentare

Majoritatea dezvoltatorilor consideră nivelul de prezentare ca fiind doar formularele Web sau Windows care colectează și validează informații de la utilizatorii aplicației. Totuși, crearea de formulare care conțin funcționalitatea proceselor și a managementului stărilor necesare interfeței, implică duplicarea acestor funcții pentru fiecare mașină client. Din acest motiv, prezentarea ar trebui împărțită în două subnivele separate. Interfața utilizatorilor va fi compusă din formularele necesare pentru procesarea informațiilor primite sau pentru afișarea informațiilor preluate de la nivelul de reguli operaționale. Totuși, informațiile despre stările proceselor (ordinea de prelucrare) ar trebui menținute într-o componentă separată de proces. Această componentă poate organiza procesele utilizatorilor fie că va fi inițializată de un client Web.

3.3. Implementarea nivelului de reguli operaționale (BusinessLogic)

Componentele acestui nivel primesc cereri de la componente de proces ale utilizatorilor. Aceste cereri sunt traduse în acțiuni controlate conform regulilor stabilite. Ele sunt responsabile de asemenea de interfața cu diferite sisteme externe pentru a da componentelor de proces percepție de nivel unificat din care aceste pot folosi un set de servicii standar. Funcțiile acestui nivel pot fi descompuse în trei tipuri componente : fluxul de lucru, regulile de validare, și agenții de servicii sau procesele.

Componentele fluxuli de lucru se vor ocupa de managementul proceselor dar vor folosi componentele regulilor operaționale pentru a impune reguli. O dezvoltare corectă a componentelor fluxului de lucru pentru aplicații diferite trebuie să implice utilizarea acelorași componente ale regulilor operaționale.

Adesea, funcțiile necesare unei aplicații au fost deja implementate în alte sisteme. Pentru a nu relua acest proces, aceste servicii pot fi preluate din nivelul de logica. Pentru a face consistente interfețele componentelor, ar trebui dezvoltate un set de procesei care vor folosi resurse externe pentru a crea această fațadă comună. Astfel, fie ca serviciul extern este unul web, sau o sesiune pe un mainframe sau chiar o componentă EJB, reprezentarea internă poate fi o componentă consistență a interfeței.

3.4. Implementarea nivelului de date

Deși implementarea accesului la date este destul de simplă, există o dezabatere despre cum ar trebui folosite în mod corect aceste componente. Părerile sunt impărțite între stocarea regulilor operaționale în proceduri și folosirea bazei de date doar pentru optimizarea accesului la date. O concluzie generală, derivată din nevoia decongestionarii unui astfel de sistem ar fi folosirea exclusivă a bazei de date pentru operații de creare, citire, modificare și ștergere (CRUD).

Trebuie evitata logica si prelucrarea datelor pe nivelul de date deoarece fiecare nivel se ocupa cu responsabilitatea lui.

3.5. Maparea obiectelor ORM

Un ORM in informatică este o tehnică de programare pentru conversia de date între sisteme de tip incompatibile în date orientate obiect pentru limbajele de programare. Acest lucru creează, de fapt, o "bază de date obiect virtual", care poate fi utilizat din interiorul limbajul de programare. Există atât de pachete gratuite și comerciale disponibile care efectueaza cartografiere obiect relational, deși unele programatori opta pentru a crea propriile instrumente ORM.

In programarea orientata-obiect, sarcinile de management de date acționează în (OO) obiecte orientate-obiect, care sunt aproape întotdeauna valori non-scalare. De exemplu, ia în considerare o intrare agendă care reprezintă o singură persoană, împreună cu zero sau mai multe numere de telefon și zero sau mai multe adrese. Acest lucru ar putea fi modelat într-o punere în aplicare orientate-obiect de un "obiect Person" cu atribute / domenii să dețină fiecare element de date care intrarea conține: numele persoanei, o listă de numere de telefon, precum și o listă de adrese. Lista de numere de telefon ar sine conține "obiecte Număr de telefon" și așa mai departe. Intrarea agendă este tratat ca un singur obiect de limbajul de programare (poate fi referite de o singură variabilă care conține un pointer la obiect, de exemplu). Diverse metode pot fi asociate cu obiectul, cum ar fi o metodă de a reveni numărul preferat de telefon, adresa de domiciliu, și așa mai departe.

Cu toate acestea, multe produse de baze de date populare, cum ar fi sistemele de gestionare a bazelor de date lingvistice de interogare structurat (SQL DBMS) pot stoca doar și manipula valori scalare, cum ar fi întregi și șiruri organizate în tabele. Programatorul trebuie să fie conversia valorilor obiect în grupuri de valori simple pentru depozitare in baza de date (și de a le converti înapoi la extragerea), sau de a folosi doar valori simple scalare în cadrul programului. Cartografiere obiect relațional este folosit pentru a pune în aplicare prima abordare.

Inima problemei traduce reprezentarea logică a obiectelor într-o formă atomizată, care este capabil să fie stocate în baza de date, păstrând în același timp proprietățile obiectelor și relațiile lor, astfel încât acestea să poată fi reîncărcate ca obiecte atunci când este necesar. Dacă această funcționalitate stocare și regăsire este implementat, obiectele se spune ca sunt persistente.

Unul dintre cele mai cunoscute si folosit este Entity Framework care permite o integrare usoara prin intermediul programului Visual Studio.Acest ORM vom folosi si in dezvoltarea aplicatiei practice.

3.6 Baze de date

O bază de date, uneori numită și bancă de date (abreviat BD), reprezintă o modalitate de stocare a unor informații și date pe un suport extern (un dispozitiv de stocare), cu posibilitatea extinderii ușoare și a regăsirii rapide a acestora. La prima vedere sarcina poate părea banală. Totuși, în condițiile în care este vorba de a lucra cu milioane de elemente, fiecare putând consta din mari cantități de date care trebuie accesate simultan prin Internet de către mii de utilizatori răspândiți pe întreg globul; și în condițiile când disponibilitatea aplicației și datelor trebuie să fie permanentă (de ex. pentru a nu pierde ocazia de a încheia afaceri), soluțiile bune nu sunt de loc simple.

De obicei o bază de date este memorată într-unul sau mai multe fișiere. Bazele de date sunt manipulate cu ajutorul sistemelor de gestiune a bazelor de date.

Cel mai răspândit tip de baze de date este cel relațional, în care datele sunt memorate în tabele. Pe lânga tabele, o bază de date relațională mai poate conține: indecși, proceduri stocate, declanșatori, utilizatori și grupuri de utilizatori, tipuri de date, mecanisme de securitate și de gestiune a tranzacțiilor etc.

Alte tipuri de baze de date sunt modelul ierarhic, modelul orientat pe obiecte și, mai nou, modelul XML.

Capitolul 4. . Prezentare modelului MVC pe platforma .NET si repository pattern

4.1. Inițializare, contextul

In general, scopul multor computere este acela de a prelua informatii dintro anumita locatie, de a o prelucra dupa preferintele utilizatorului si, in cele din urma, de a o afisa utilizatorului. Dupa ce utilizatorul modifica continutul informatiei si dupa aplicarea unor eventuale procesari aditionale, sistemul reinoieste informatia in locul de unde a preluat-o initial. Cea mai usoara metoda de a realiza o aplicatie care realizeaza aceste operatii este de a pune laolalta operatiile si de a le trata ca pe un tot. Aceasta metoda este buna in sensul ca este usor de implementat. Ulterior apar insa probleme cand se doreste schimbarea uneia din componentele fluxului de date, spre exemplu atunci cand se doreste schimbarea interfetei. O alta problema tine de logica de business ce trebuie incorporata, logica care si ea este supusa schimbarilor si care merge dincolo de simpla interschimbare de informatie.

4.2. Problema flexibilitatii si testabilitatii.

Apare asadar nevoia de a modulariza aplicatia, de a delimita in mod clar partile componente spre a putea fi usor modificate si ca dupa modificare sa fie inca compatibile cu celelalte module ce formeaza aplicatia intr-un cuvant flexibilitatea.

A doua problema a unei aplicatii care nu este modulara este testabilitatea, nu se poate testa codul de logica daca el este incorporat in interfata sau nu se poate testa accesul la baza de date separat de restul aplicatie iar pentru aceasta problema ne vom ocupa mai tarziu cand vom discuta despre arhitectura pe mai multe nivele.

4.3. Solutia

O solutie la aceasta problema este arhitectura Model-View-Controller (MVC) care separa partea de stocare a datelor de cea de prezentare si de prelucrare.

Avem asadar trei clase distincte:

Model-ul se ocupa cu reprezentarea datelor dar poate face si actiuni de logica; raspunde la cereri despre starea sistemului, la cereri de schimbare de stare si notifica utilizatorul atunci cand aceste schimbari au avut loc pentru ca acesta sa poata reactiona.

View-ul transpune model-ul intr-o forma care permite o interactionare usoara, in mod tipic o interfata vizuala. Pot exista multiple view-uri pentru un singur model pentru scopuri diferite.

Controller-ul primeste input de la utilizator si initiaza un raspuns in urma cererilor catre obiectele model. Controller-ul este cel care controleaza celelalte doua clase de obiecte, view si model, instructandu-le sa execute operatii pe baza input-ului primit de la utilizator.

Fig. 11 Diagrama arhitecturii MVC prezinta liniile ca asocieri directe.

4.4. Scurt Istoric

Istoric MVC a fost descris pentru prima oara in 1979 de catre Trygve Reenskaug care pe vremea aceea lucra la Smalltalk din cadrul Xerox PARC.

4.5. MVC Structura de fișiere și standardele pentru denumire

MVC foloseste o structura de directoare standard si de denumire a fișierelor standarde care sunt o parte foarte importantă din dezvoltarea de aplicatii MVC.

În interiorul directorul rădăcină al cererii, trebuie să existe 3 directoare, fiecare pentru modelul, vedere și controler.

În afară de 3 directoare, trebuie să aibă un fișier Global.asax în folderul rădăcină, și o web.config ca o aplicație tradițional ASP.NET.

Fig. 11

4.6. Implementare

O aplicatie orientata pe principiile MVC poate fi o colectie de triade model/view/controller, fiecare responsabila de un element diferit al interfetei cu utilizatorul. MVC este des intalnit in in aplicatii web unde view-ul este codul HTML generat de aplicatie. Controller-ul primeste variabile GET si POST ca si input si decide ce sa faca cu acestea, trimitandu-le mai departe model-ului. Model-ul, care contine logica de business si regulile aferente, poate efectua operatiile necesare asupra datelor pentru a putea permite aplicatiei generarea codului HTML mai sus mentionat via engine-urile de template, pipeline-uri XML, cereri de tip Ajax, etc. Model-ul nu este neaparat doar o baza de date, fiind adesea atat baza de date cat si logica de business necesara pentru a manipula datele in interiorul aplicatiei.Aici intervine o discutie filozofica intre arhitecti si avem diferite recomandari, prima ar fi sa se pastreze modelul simplu, curat fara logica, doar pentru reprezentarea datelor si adaugarea unui nivel suplimentar care sa fie referentiat in celelalte nivele iar logica sa fie pusa pe nivelul de logica si a doua propunere este ca in modele sa existe cod de logica pentru ca controllerul sa fie cat mai simplu. Multe aplicatii folosesc un mecanism persistent de stocare a datelor. MVC nu specifica in mod explicit nivel de acces la date tocmai pentru ca este de la sine inteles ca acesta se afla incapsulat in model. In unele aplicatii simple care au putine reguli de business logic impuse, model-ul se poate limita doar la o baza de date si la functionalitatile oferite de aceasta.

View-ul, de asemenea nu este limitat doar la afisarea informatiei, el avand un rol important si in interactiunea cu utilizatorul. In cazul exemplului de mai sus al aplicatiilor web interfata generata via cod html este cea care se ocupa si de preluarea input-ului si de masurile luate pentru ca acesta sa fie corect. Controller-ul este adesea confundat cu aplicatia insasi, pe cand rolul sau este de a dirija datele intre celelalte doua clase de obiecte. Intr-adevar, se pot executa multe operatii asupra datelor de catre model, insa aceste operatii tin de formatul in care se prezinta datele la un moment dat. Adesea se intalneste cazul in care datele afisate/culese de la utilizator difera semnificativ de cele stocate in baza de date. Aceste diferente se datoreaza conversiilor ce pot fi aplicate asupra datelor de catre controller pentru a facilita traficul de informatie intre componente. Fiecare clasa de obiect are anumite expectative definite in ceea ce priveste formatul datelor, ori aceste transformari de format trebuie realizate automat pentru a mentine un flux constant de date, degrevand celelalte clase de grija conversiilor si asigurand aplicatia ca fiecare modul primeste ceea ce asteapta. Asta pe langa functia de baza de controla traficul de cereri intre module.

4.7. Functionare aplicatie .

Schema de functionare a unei aplicatii modelate dupa arhitectura MVC decurge, in linii mari, in felul urmator:

Userul interactioneaza cu interfata. (exemplu: apasa un buton la tastatura)

Controller-ul primeste actiunea apasarii butonului si o converteste intr-o actiune pe intelesul model-ului.

Controller-ul notifica model-ul de actiunea utilizatorului, urmand de obicei o schimbare a starii model-ului. (exemplu: model-ul reimprospateaza starea campului de adresa)

Un view interogheaza model-ul pentru a genera o interfata corespunzatoare. (exemplu: view-ul afiseaza noua adresa alaturi de cea veche alaturi de un buton de confirmare) 5. Interfata asteapta actiuni suplimentare din partea utilizatorului, ciclul reluandu-se.

Ciclul de viata al unui request in MVC

Fig.14

Requestul este interceptat prima data de modulul de rutare care este un modul HTTP. Acest modul este responsabil de a decide daca aceasta cerere poate fi procesata de aplicatia MVC.Tabela de rutare selecteaza prima ruta care se potriveste

Fig.12

Modulul de rutare stie care sunt rutele permise pentru aplicatie din fisierul Global.asax, fisier existent in proiectul nostru, in acest fisier fiind definite rutele.

Exista o ruta din oficiu pe care fiecare aplicatie o are dar se poate defini si alte rute in functie de nevoia dezvoltatorului iar un exemplu putem vedea in figura urmatoare.

RouteConfig.RegisterRoutes(RouteTable.Routes);
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(
name: "Default",
url: "{controller}/{action}/{id}",
defaults: new { controller = "Home", action
= "Index", id = UrlParameter.Optional }
);
}

Fig.14

Dupa tabela de rutare este chemat controller-ul specificat in cererea primita de la utilizator si metoda cu parametrii care se ocupa de procesarea cererii.

Dupa executarea metodei controlerul proceseaza datele dupa care se returneaza un ActionResult care poate fi de mai multe tipuri, view, json, xml iar date sunt returnate la interfata utilizator de unde s-a facut cererea.

4.8 Repository Pattern

În inginerie software, un model de design (desing pattern) este o soluție reutilizabil general o problemă frecvent apare într-un context dat in proiectarea aplicatiilor software. Un model de design nu este un design terminat care pot fi transformate direct în sursă sau cod mașină. Este o descriere sau șablon pentru modul de a rezolva o problemă care poate fi folosit în multe situații diferite. Modele sunt formalizate cele mai bune practici care programatorul poate utiliza pentru a rezolva problemele comune la proiectarea unei aplicații sau sistem. Modele de design orientat-obiect arată de obicei relațiile și interacțiunile dintre clase sau obiecte, fără a specifica clasele de aplicare finali sau obiectele care sunt implicate. Modele care implică obiect-orientare sau, mai general, de stat mutabil, nu sunt la fel de aplicabile în limbaje de programare funcțională.

4.8 .1 Context

În multe aplicații, logica de afaceri accesează date din magazinele de date, cum ar fi bazele de date, liste SharePoint sau servicii Web. Accesarea directă a datelor poate duce la următoarele:

Codul duplicat

Un potențial mai mare pentru erori de programare

Tastarea slab datelor de afaceri

Dificultate în centralizarea politicilor legate de date, cum ar fi caching

Incapacitatea de a testa cu ușurință logica de afaceri separat de dependențe externe

4.8.2 Obiective

Utilizați modelul Repository pentru a realiza una sau mai multe dintre următoarele obiective:

Vrei pentru a maximiza cantitatea de cod care pot fi testate cu automatizare și pentru a izola stratul de date care să susțină unitate de testare.

Accesați sursa de date de la mai multe locații și doriți să aplicați gestionate la nivel central, regulile de acces coerente si logice.

Vrei să pună în aplicare și centraliza o strategie caching pentru sursa de date.

Vrei să îmbunătățească mentenabilitatea codului și lizibilitatea prin separarea logica de afaceri de date sau logica acces service.

Doriți să utilizați entități de afaceri, care sunt puternic tastate, astfel încât să puteți identifica problemele în timpul compilării în loc de la momentul execuției.

Vrei să asocieze un comportament cu datele aferente. De exemplu, doriți să calculeze domenii sau impune relații complexe sau reguli de afaceri între elementele de date din cadrul unei entități.

Doriți să aplicați un model de domeniu pentru a simplifica logica de afaceri complex.

4.8.3 Soluție

Folosiți un depozit pentru a separa logica care preia datele și hărți se la modelul entitate de logica de afaceri care acționează pe modelul. Logica de afaceri ar trebui să fie agnostic cu tipul de date care cuprinde stratul de sursă de date. De exemplu, stratul de sursă de date poate fi o bază de date, o listă SharePoint, sau un serviciu Web.

Magazia mediază între stratul de sursă de date și straturile de afaceri ale cererii. Acesta interogări sursa de date pentru date, hărți datele din sursa de date pentru o entitate de afaceri, și persistă schimbări în entitatea de afaceri la sursa de date. Un depozit separă logica de afaceri din interacțiunile cu sursa de date care stau la baza sau serviciul Web. Separarea dintre date și de afaceri niveluri are trei avantaje:

Centralizeaza logic de date sau serviciu Web logica de acces.

Acesta oferă un punct de substituție pentru testele unitare.

Acesta oferă o arhitectură flexibilă, care poate fi adaptată ca designul general al evoluează aplicare.

Există două moduri în care depozitul de poate interoga entități de afaceri. Se poate depune un obiect interogare logica de afaceri clientului sau poate folosi metode care specifică criteriile de afaceri. În acest ultim caz, magazia formează interogarea în numele clientului. Magazia returnează un set de potrivire de entități care satisfac interogarea. Următoarea diagramă prezintă interacțiunile magazia cu clientul și sursa de date.

Fig. 1.1

Clientul prezintă entități noi sau modificate la magazia de persistență. În mai multe situații complexe, logica de afaceri client poate utiliza unitatea de model de lucru. Acest model demonstrează cum se îngloba mai multe operațiuni legate de faptul că ar trebui să fie coerente între ele sau care au dependențe legate. Elementele încapsulate sunt trimise la magazia de actualizare sau șterge acțiuni. Aceasta orientare nu include un exemplu al Unității de model de lucru. Pentru mai multe informații, consultați Unitatea de lucru pe site-ul Martin Fowler lui.

Capitolul 5. Testabilitatea aplicatiilor

5.1 Introducere

Când vom crea o bibliotecă C # (API consumate de alte aplicații) nu suntem siguri cum ar putea fi posibilele utilizări ale acestuia de către dezvoltator de aplicații. Acestea pot transmite informații incorecte argument pentru funcțiile noastre API. Pentru a valida toate scenariile de care avem nevoie pentru a crea cod care va verifica și valida metodele noastre API.

Uneori avem nevoie pentru a modifica metodele noastre și nu avem timp să facem teste de fum. În astfel de scenarii, dacă avem o unitate de testare automat atunci putem verifica cu ușurință dacă pauze nimic. Pentru a valida succes metodele noastre / Clasa, avem nevoie pentru a atinge cod mai acoperire pentru codul nostru.

5.2 Testul automat.

Un test automat este testarea a unei parti a aplicatiei pentru a ne asigura faptul ca aplicatia functioneaza conform asteptarilor si cerintelor clientului.In visual studio avem suport pentru crearea de unit teste, facem click dreapta pe solutie si putem adauga un test automat.

Fig. 11

In interiorul unui unit test putem avea mai multe metode decorate cu atributul “[TestMethod]” in interiorul carora putem face logica de testare a aplicatiei noastre.In metoda de test scrisa mai jos se verifica daca vectorul de striguri contine textul asteptat , iar verificare se face cu ajutorul metodei Assert care va returna test trecut cu succes sau va arunca exceptie in cazul in care datele din vectorul de string nu este in concordanta cu stringul asteptat.

Exemplu de test automat il avem in codul urmator:

[TestMethod]
public void PossitiveSchenarioForChecking_combineArrayStringWithSpace()
{
string expectedResult = "Astazi este o zi calduroasa";
string[] actualStringArray = new string[] { "Astazi", "este ", "o", "zi", "calduroasa"};
ApplicationCodeClass appObject = new ApplicationCodeClass();

string actualResult = appObject.combineArrayStringWithSpace(actualStringArray);

Assert.AreEqual<string>(expectedResult, actualResult);

}

Fig. 11

Visual Studio Test de Explorer este conceput pentru a sprijini dezvoltatorii și echipe care încorporează unitate de testare în practicile lor de dezvoltare de software. Unitate de testare vă ajută să asigure corectitudinea programului prin verificarea faptului că codul aplicatiei face ceea ce vă așteptați să facă. În unitate de testare, sa analizati functionalitatea programului pentru a descoperi comportamente discrete testabile pe care le puteți testa ca unități individuale. Puteți utiliza un cadru de testare unitate pentru a crea teste de acele comportamente și să raporteze rezultatele acestor teste.

Unitate de testare are cel mai mare efect atunci când este o parte integrantă a fluxului de lucru de dezvoltare de software. De îndată ce scrie o funcție sau alt bloc de cod aplicare, creați teste unitare care verifica comportamentul codului răspuns la standardul, limita, iar cazurile incorecte ale datelor de intrare, precum și că verifică toate ipotezele explicite sau implicite realizate de cod. Într-o practică de dezvoltare de software, cunoscut sub numele de testare condusă de dezvoltare, să creați teste unitare înainte de a scrie cod, astfel încât să utilizați teste unitare ca atât documentația de proiectare și specificațiile funcționale ale funcționalității.

Testare Explorer oferă un mod flexibil și eficient pentru a rula testele unitare și a vizualiza rezultatele în Visual Studio. Visual Studio instalează cadrele de testare unitate Microsoft pentru cod gestionat și nativ. Încercare Explorer poate rula, de asemenea, terțe părți și cadre deschise de teste unitare sursă care au implementat test Explorer pe interfețe. Puteți adăuga mai multe din aceste cadre prin Visual Studio Managerul Extinderea și galeria Visual Studio. Vezi Cum să: Instalarea Cadrele terți unitate de testare

Fig.101

Vizualizari încercare Explorer poate afișa toate testele, sau doar testele care au trecut, nu a reușit, nu au fost rulate inca, sau au fost omise. Puteți filtra testele în orice vizualizare de potrivire de text în caseta de căutare la nivel mondial sau prin selectarea uneia dintre filtrele predefinite. Puteți rula orice selecție de teste, în orice moment. Când utilizați Visual Studio Ultimate, puteți rula teste în mod automat după fiecare build. Rezultatele unui test sunt vizibile imediat în trecere / eșec bar în partea de sus a ferestrei Explorer. Detalii privind un rezultat metode de testare sunt afișate atunci când selectați testul.

5.3. Problema dependentelor

Pentru ai ilustra mai bine problema dependentelor am creat o aplictie demonstrativa in care incercam sa rezolvam aceasta problema.

Dupa cum putem vedeam in aplicatia de demo din urmatoarea diagrama arhitectura este impartita pe 3 nivele, primul nivel este cel de prezentare unde am ales o aplicatie pe arhitectura MVC, al doilea nivel este nivelul de logica pe care il numim BusinessLogic, acest nivel fiind responsabil de logica aplicatiei noastre si de comunicarea cu nivelul 3 care este nivelul de acces la baza de date si il numim DAL del a Data Access Layer.

Fig. 11

Adaugam in folderul de Controller din nivelul de prezentare un nou controler numit PersonController care va prelua cererile de administrare a unei persoane venite de pe partea de client-side si se va ocupa de avisarea view-rilor.

Adaugam in nivelul de logica o noua clasa numita PersonBusinessObject care se va ocupa de logica entitatii person, va comunica cu nivelul de acces la baze de date pentru stocarea si manipularea bazei de date.PersonBusinessObject va fi folosit in PersonController, controllerul nu va accesa baza de date direct ci prin intermediul obiectului de logica PersonBusinessObject.

PersonDataAccess va fi obiectul care va interga baza de date pentru opreatiile de CRUD si va returna rezultatul interogarii nivelului de business care va decide logica aplicatiei.

Dupa cum observam in diagrama de mai sus avem niste dependente intre nivelele arhitecturii, adica nivelul de prezentare foloseste nivelul de business deci are nevoie de o referinta intre nivelul de prezentare si cel de logica.Nivelul de BusinessLogic foloseste nivelul de acces si are nevoie de o referinta si o instanta de PersonDataAccess pentru a interoga baza de date.

Fig.2.1. Clasa de acces a bazei de date.

In figura urmatoare avem Clasa PersonBusinessObject care gestioneaza logica legata de entitatea Person,si metoda AddPerson care va chema metoda de validare persoana ValidatePersonModel() dupa care va adauga o noua persona in baza de date.

Fig.2.1. Modulul de logica.

Presupunem ca vrem sa testam logica metodei AddPerson() fara a ne conecta la baza de date, facem abstracte de tipul bazei de date pentru ca asta urmarim ca logica aplicatie sa fie independenta, sau decuplata de nivelul de acces la baza de date, lucru care nu este posibil la arhitectura noastra. Dupa cum putem vedea in diagrama urmatoare unde am creat un unit test pentru metoda AddPerson() in care am adaugat instanta de PersonBusinessObject, un obiect tip person si am fost nevoiti sa specificam si accesul la baza de date.

Dupa cum se poate vedea mai sus in diagrama metodei AddPerson se foloseste nivelul de acces la baza de date si se fac interogari si modificari direct pe baza de date, baza de date ramanand intr-o stare degradata, nu putem modifica codul din nivelul de acces ca sa nu faca inserturile pentru ca riscam sa introducem bug-uri , nu este ceea ce ne dorim.Pentru a putea testa corect metodele de logica din aplicatia noastra si pentru a avea flexibilitate in ceea ce priveste nivelul de data access avem nevoie de abstractizari si implementarea principiilor de desing (OOD) principiile numite SOLID.

Fig.2.1. Unit test metoda adaugare persoana

5.4. Rezolvarea problemei dependentelor

Pentru a rezolva dependenta nivelului de logica fata de nivelul de data access avem nevoie de impementarea unei abstractizari.

Unul din cele cinci principii spune ca legaturile sau dependentele nu trebuiesc sa depinda de clasa concreta ci de abstractizare.In arhitectura noastra nivelul de logica depinde de nivelul de acces la date, data access fiind o clasa concreta.Ceea ce spune inversarea dependentelor este ca sa nu folosim dependente concrete.

Deci vom inlocui dependenta de PersonDataAccess cu o interfata IPersonDataAccess in care vom abstractiza metodele cu care vom lucra in clasa concreta.O interfata este un contract pe care o clasa care o implementeaza trebuie sa il respecte.Dupa cum vedem in diagrama urmatoare am creat abstractizarea pentru nivelul de acces.

Fig.2.1. Abstractizare modul acces baza de date.

Modificam si in nivelul de logica proprietatea PersonDataAccess sa fi IPersonDataAccess iar PersonDataAccess va implementa interfata IPersonDataAccess fiind o clasa concreta.

Prin aceste modificari ne-am asigurat flexibilitatea arhitecturii, doarece putem schimba usor baza de date din SQL in MYSQL sau altceva cu conditia ca DAL-ul sa impementeze interfata IPersonDataAccess si in al doilea rand testabilitatea aplicatiei, putem testa logica fara a accesa baza de date fizic,putem simula date pe care vrem sa se faca testarea fara a periclita baza de date.

Fig.2.1. Inițializarea modului graphic

Prin aceasta implementare concreta ne putem testa metoda noastra simuland diferite scenarii de date si evenimente iar testul nostru ramane aproape neschimbat, codul din nivelul de logica nu va suferii modificari pentru teste sau schimbarea ORM-ului.

Fig.2.1. Inițializarea modului graphic

5.3 Testarea aplicatiilor, AngularJS.

JavaScript este un limbaj dinamic tastat, care vine cu o mare putere de expresie, dar, de asemenea, vine cu aproape nici un ajutor de compilator. Din acest motiv, credem cu tărie că orice cod scris în JavaScript trebuie să vină cu un set puternic de teste. Am construit multe caracteristici în coltare care face testarea aplicațiilor unghiulare ușor. Deci, nu există nici o scuză pentru a nu testarea aplicatia pe partea de interfata utilizator.

In cele ce urmeaza vom discuta putin despre Arhitectura platformei de dezvolare AngularJS.

5.4 Separarea responsabilitatilor

Unitate de testare, așa cum sugerează și numele, este vorba de testarea unități individuale de cod. Teste de unitate încerca să răspundă la întrebări, cum ar fi "este corecta logica mea?" sau "Are funcția de sortare a comanda lista în ordinea corectă?"

În scopul de a răspunde la o astfel de întrebare este foarte important că putem izola unitatea de cod testat. Asta se datorează faptului că atunci când suntem testarea funcției de sortare nu vrem să fie forțat în crearea de piese conexe, cum ar fi elementele DOM, sau de a face orice XHR apeluri pentru a prelua datele pentru a sorta.

În timp ce acest lucru poate părea evident, poate fi foarte dificil pentru a apela o funcție individuală la un proiect tipic. Motivul este că dezvoltatorii se amestecă adesea se referă la rezultate într-o bucată de cod care face totul. Se face o cerere XHR, se sortează datele de răspuns și apoi manipuleaza DOM.

Cu unghiulară vom încerca a face mai ușor pentru tine de a face ceea ce trebuie, si asa vom oferi injectare dependență de solicitările dumneavoastră XHR, care pot fi batjocorit, și oferim abstracțiuni care vă permit să testați modelul fără să recurgă la manipularea DOM. Testul poate afirma atunci că datele au fost sortate fără a crea sau se uite la starea de DOM sau așteptați pentru cererile XHR să se întoarcă de date. Funcția sortare individuală pot fi testate în mod izolat.

5.5 Forta si responsabilitate

Unghiulară este scris cu testabilitate în minte, dar încă necesită să faci ceea ce trebuie. Am încercat să facă un lucru bun ușor, dar dacă ignora aceste linii directoare ar putea termina cu o necessitate de testare.

5.6 Injectarea dependentelor.

AngularJS vine cu injecție petnru dependență incorporat, ceea ce face componente sa fie testate mult mai ușor.Componentele care au dependențele lor injectate le permite să fie ușor de simulate pe un test de bază, fără a fi nevoie să te pui cu orice variabile globale care ar putea afecta din greșeală un alt test..

5.7 Testarea un controler

Deoarece angular separă logica din stratul vedere, pastreaza contolerele ușor de testat. Să aruncăm o privire la modul în care am putea testa controlerul de mai jos, care prevede $ scope.grade, care stabilește un grad de dificultate al parolei în funcție de lungimea parolei.

angular.module('app', [])

.controller('PasswordController', function PasswordController($scope) {

$scope.password = '';

$scope.grade = function() {

var size = $scope.password.length;

if (size > 8) {

$scope.strength = 'strong';

} else if (size > 3) {

$scope.strength = 'medium';

} else {

$scope.strength = 'weak';

}

};

});

Fig. 12

Deoarece controlalele nu sunt disponibile pe domeniul de aplicare la nivel global, avem nevoie pentru a utiliza angular.mock.inject pentru a injecta controlerul. Primul pas este de a utiliza funcția modul, care este furnizată de angular. Aceasta încarcă în modul este dat, deci este disponibil în testele. Vom trece acest lucru în beforeEach, care este o funcție Jasmine prevede că ne permite să ruleze cod înainte de fiecare încercare. Atunci putem folosi pentru a accesa injectează $ controler, serviciul care este responsabil pentru instantierea controlului.

5.8 Concepte de baza AngularJS

Descriem in contiuare cateva concepte de baza legate de platform de dezvoltare angular.js.

Dezvoltarea aplicatiilor cu ajutorul platformelor de dezvoltare javascript ca AngularJS oferta un mediu structurat, testabil si a inregistrat o crestere de utilizare semnificativa.

Capitolul 6. Dezvoltarea aplicatiei.

Utilizare si rezultate.

6.1. Structura solutiei

Fig.11

Aplicatia este construita pe mai multe nivele arhitecturale dupa cum am prezentat mai sus aplicatia se vrea a fi o aplicatie testabila ,fexibila si usor de intretinut.

Nivelele arhitecturale sunt:

Nivelul de prezentare numit Smart.Web unde avem un proiect pe structura MVC Asp.net integrat cu identity pentru gestionea utilizatorilor, structura de foldere este urmatoarea:

Fig. 10

Nivelul de logica Smart.BusinessLogic care ne asigura legatura dintre nivelul de acces la baza de date si nivelul de prezentare, ne ajuta la mentinerea controlerului cat mai simplu si curat si grupeaza logica unei entitati intr-un singur loc.

Fig. 11

Nivelul de acces al bazei de date este locul unde avem implementat un abstract repository pattern

Fig 1.1

Nivelul de model pentru accesul modelelor in toata structura aplicatiei.

Fig.11

6.2. Tehnologii folosite

Pentru partea de frontend se folosesc tehnologii ca :

Libraria BootStrap – pentru un desing adaptiv la ecrane diferite, ofera o gama larga de clase css predefinite.

Libraria JQuery – pentru manipularea DOM-ului, animatii.

Libraria Moris si Chart.js – pentru afisarea graficelor

Libraria jQuery nicescroll – pentru afisarea scrolului intru mod mai placut.

AngularJS – framework MVC javascript.

Pentru partea de server se folosesc tehnologii ca :

Asp.net MVC integrat cu identity pentru management utilizatori.

Entity Framework – pentru manipularea bazei de date.

6.3. Pagina principal

Aplicația este construită pe mai multe componente vizuale.

Fig. 12

In pagina principal avem meniul vertical stanga care se poate ascunde in partea stanga cu linkuri de navigare catre pagina de detaliu venituri, cheltuieri,analiza, rapoarte,setari. In bara de sus de culoare galbena avem de la stanga la dreapta buton de ascundere meniu,logo aplicatie cu link catre pagina principal, butoanele pentru notificari si mesaje iar in partea dreapta avem butonul de inregistrare sau autentificare.

Pe partea dreapta avem bara de notificari despre ultimele operatii effectuate si un calendar format lunar. In centru avem detalii despre bugetul actual pe 3 categorii: venituri, cheltuieli si sold disponibil pe luna selectatata in meniul din centru paginii si cele 2 butoane cu caracterul “+” pentru adaugare tranzactie noua iar butonul galben cu semnul ”>” pentru vizualizare detalii disponibilitate lichiditati.In partea de jos sunt afisate grafice cu detalii despre cheltuielile pe ultimul an. ). Corespondența butoanelor este trecută ȋn tabelul următor:

6.4. Desing adaptive.

Aplicatia a fost dezvoltata pe principiul mobile-first si s-a folosit clasele predefinite de la bootstrap in colaborare cu mediaQuery pentru redimensionarea elementelor si rearanjarea acestora in functie de rezolutia vizitatorului.

Fig.12

6.4. Pagina de autentificare

Pagina de autentificare este pagina unde utilizatorul trebuie sa se autentifice pentru a putea folosi aplicatia.Fiecare utilizator are un cont propriu care poate fi accesat de pe orice dispozitiv care dispune de un navigator de internet.In figura x avem fereastra de autentificare cu campul text User ID care reprezinta numele de utilizator si campul de parola Password.Sub aceste campuri avem si link-ul catre pagina de resetare parola “Forgot Password?” si butonul “Sign In” care trimite cererea de autentificare.

Fig. 11

Pagina de setari

Pagina de detaliere venituri pe categorii

In pagina de venituri pe categorii avem un grafic care la intrarea pe pagina este animat si ne arata categoriile pentru venituri, iar daca punem mouse-ul deasupra unei portinuni din graphic ne este afisata suma totala de venituri pentru categoria respective, o categorie este desenata cu o singura culoare.Sub acest grafic avem o lista cu categoriile de venit pentru utilizatorul autentificat,cu coloanele numlele categoriei, total suma venit pe categoria respective, pentru vizualizare detaliu categorie si editare nume categorie.Pentru a naviga in pagina de detaliu pentru o categorie se poate face clik si pe numele categoriei.

Fig.12

Pagina de detaliere cheltuieli pe categorii

Pagina detaliere cheltuieli seama cu pagina pentru detaliu venituri diferenta fiind colona de status pentru ca putem avea o tranzactie in curs de efectuare, in plan sa fie efectuata sau efectuata.

Fig.12

Pagina de adaugare venituri

Pentru adaugarea de venituri si cheltuieli avem doua posibilitati, fie prin pagina de adaugare venit(figura r) sau prin fereastra de adaugare din figura x.

In acest formular de adaugare venit nou avem urmatoare campuri care trebuiesc completate pentru adaugarea unui nou veni:

Category – o lista cu optiuni de tip categorie din care se poate selecta o singura valoare

Descryption – descrierea venitului care poate fi selectat sau poate fi introdus unul nou.

Amount – canitatea sau suma care a fost incasata

Date – data la care a fost facuta tranzactia, este un selector de data oferit de libraria bootstrap.

Butonul Save – butonul care face submint la formularul de adaugare venit; acest buton devine activ atunci cand toate datele sunt completate corect, in alt caz butonul va ramane neactiv. Daca formularul este completat corect si se apasa acest buton datele vor fi salvate in baza de date dupa care vom fi redirectati catre pagina de detaliu venit pentru categoria adaugata anterior.

Butonul Cancel – buton prin care ne scoate din pagina de adaugare venit si ne redirecteaza catre pagina de categorii venituri.

Fig.11

A doua posibilitate de adaugare venituri sau cheltuieli este prin urmatoare fereastra care este afisata la apasarea butonului de “+” din pagina principala pe tranzactia dorita.La apasarea acestui buton se deschide un modal ca cel din figura si se blocheaza accesul la celelalte elemente a paginii pana aceasta fereastra este inchisa. Daca avem tranzactii care se repeta lunar putem bifa casuta de plata repetata si in fiecare luna la ziua in care a fost introdusa tranzactia va fi introdusa o tranzactie similara.Butonul cu iconita de calendar ne permite selectarea unei anumite zile din luna, an print-o fereastra ca cea din figura x;

Fig 10 Fig 10

Panelul de notificari

In casta de notificari primim date despre statusul bugetului nostru si ultimele opratiuni executate de catre utilizatorul autentificat precum si notificari setate pentru anumite categorii sau produse.

Fig. 11

Panel mesaje

Aplicatia permite faptul ca doi utilizatori sa poata imprtasi un anumit plan si sa lucreze impreuna la gestiunarea unei familii un exemplu ar fi un sot si o sotie, sau organizarea unei mici afaceri unde sunt mai multi asociati si se vrea transparent in utilizarea fondurilor deacea a fost nevoie si de implementarea unui system de transmitere mesaje intre utilizatori.

Dupa cum se vede in figura urmatoare utilizatorul autentificat are cinci mesaje de la colaboratori sai permitandu-I sa le citesca instantaneu.

Pagina de rapoarte si anliza

Statistica si raportarea datelor intr-un mediu placut, visual este foarte importanta pentru ca utilizator sa poata intelege si corecta anumite aspecte care adeseori sunt neglijate in cheltuirea banilor . Am adaugat in aplicatia noastra pagina de rapoarte unde ne este prezentata statistica pe anumite perioade de timp in functie de filtrarea utilizatorului.

Cu ajutorul istoricului de date se pot face previziuni si planifica bugetul pe anii urmatori oferind posibilitatea utilizatorului de a analiza principalele surse de venituri si cheltuieli, sa selecteze anumite segmente pentru care vrea sa primeasca analize si notificari la anumite interval de timp pentru a preveni depasirea bugetului.Un exemplu ar fi daca vrem sa ne facem un buget pe mersul la teatru si stabilim suma de 100 de dolari o notificare ca s-a deposit aceasta suma nu ar fi de folos pentru ca planul nostru este de a cheltui mai putin decat bugetul alocat.O notificare setata la interval de 10 dolari ne-ar ajuta pentru ca avem timp sa luam masuri inainte ca bugetul sa fie deposit.In figura urmatoare avem modelul de grafice utilizate in afisarea statisticilor a rapoartelor si analizei bugetului.

Fig. 12

Fig. 12

6.6. Concluzii

In concluzie aceasta arhitectura pe mai multe nivele ofera o gama larga de facilitati printre care reamintim testabilitatea, flexibilitatea, intretinerea, insa putem adauga si posibilitatea ca mai multi dezvoltatori sa lucreze impreuna la acelasi proiect pe nivele diferite, ceea ce creste productivitatea in dezvoltarea aplicatiilor si calitatea produselor soft si conduce la specializarea echipei pe anumite segmente.

Bibliografie selectivă:

Laslo E., Ionescu VS., Algoritmica C++, MatrixRom Bucuresti 2011

D. Weller, Alexander SL, Ellen H. “Beginning .NET Game Programming in C#”New Yoork 2010

http://ro.math.wikia.com/wiki/Fractal

http://ro.wikipedia.org/wiki/Fractal

http://msdn.microsoft.com/en-us/library/system.drawing.graphics.aspx

http://msdn.microsoft.com/en-us/library/system.drawing.graphics_methods.aspx

http://msdn.microsoft.com/en-us/library/system.drawing.graphics_properties.aspx

http://msdn.microsoft.com/en-us/library/5y289054.aspx

http://msdn.microsoft.com/en-us/library/aa288436(v=vs.71).aspx

Bibliografie selectivă:

Laslo E., Ionescu VS., Algoritmica C++, MatrixRom Bucuresti 2011

D. Weller, Alexander SL, Ellen H. “Beginning .NET Game Programming in C#”New Yoork 2010

http://ro.math.wikia.com/wiki/Fractal

http://ro.wikipedia.org/wiki/Fractal

http://msdn.microsoft.com/en-us/library/system.drawing.graphics.aspx

http://msdn.microsoft.com/en-us/library/system.drawing.graphics_methods.aspx

http://msdn.microsoft.com/en-us/library/system.drawing.graphics_properties.aspx

http://msdn.microsoft.com/en-us/library/5y289054.aspx

http://msdn.microsoft.com/en-us/library/aa288436(v=vs.71).aspx