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 programator va creai 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 pe 3 nivele (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 arhitectura Three-tier conține următoarele nivele de baza :

Nivelul de prezentare care mai este numit nivelul de client sau controler – acesta reprezintă cel mai inalt nivel al aplicației. Nivelul de prezentare este responsabil de procesarea cererilor venite de pe partea de client si accesare entitatii desemnate sa se ocupe de logica respectiva dupa care se returneaza un rapuns in partea de clinet care poate fi de tip view, redirect, eroare.Acest nivel comunică prin trimiterea de rezultate către nivelul browser/client, rezultate care sunt afisate utilizatorului.

Nivelul logic sau nivelul care este responsabil sa ia decizii este nivelul de mijloc – acesta este accesat de nivelul de mai sus și controlează funcționalitatea aplicației prin realizarea de procesări detaliate pentru anumite entitati.

Nivelul de persistare a datelor – acesta constă în serverele de baze de date. Cu ajutorul acestui nivel se introduc si se extrag date din baza de date.se obțin îmbunătățiri în performanță, testabilitate și scalabilitate.

3.2. Implementarea nivelului de prezentare

Majoritatea dezvoltatorilor de aplicatii soft sunt de parere ca acest nivel este doar formularele Web sau Windows care aduna și validează informațiile primite de la utilizatorii aplicației. 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. Această componentă poate organiza procesele utilizatorilor fie că va fi inițializată de un client Web.

3.3. Implementarea nivelului logica (BusinessLogic)

Acest nivel primeste cereri de procesare a datelor de la nivelul de prezentare care interactioneaza cu utilizatorii. Aceste cereri sunt traduse în acțiuni controlate conform regulilor stabilite in acest nivel. Funcțiile acestui nivel pot fi descompuse în trei tipuri de componente : fluxul de lucru, regulile de validare, și agenții de servicii sau procesele.

Nivelul de logica are obligatoriu un flux care se vor ocupa de managementul proceselor dar vor folosi componentele regulilor operaționale pentru a impune reguli. Pentu o dezvoltare cat mai corectă a fluxului de lucru este ca pentru aplicații diferite trebuie să implice utilizarea acelorași componente ale regulilor operaționale.

Este foarte des intalnit faptul ca funcțiile necesare unei aplicații au fost deja implementate în alte sisteme pe alte nivele insa pentru a nu relua acest proces, aceste servicii pot fi preluate din nivelul de logica si utilizate.

3.4. Implementarea nivelului de date (DAL)

Implementarea accesului la date pare este destul de simplă,totusi este o dezabatere filozofica 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. Pentru necesitatea decongestionarii unui 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 este o colecție de informații care sunt organizate astfel încât să poată fi accesate cu ușurință, gestionat și actualizat. Într-un singur punct de vedere, baze de date pot fi clasificate în funcție de tipuri de conținut: bibliografice, full-text, numeric, și imagini.

În calcul, baze de date sunt uneori clasificate în funcție de abordarea lor de organizare. Abordarea cea mai răspândită este de date relațională, o bază de date tabelare în care este definit de date, astfel încât să poată fi reorganizate și accesate într-un număr de moduri diferite. O bază de date distribuită este una care poate fi dispersat sau replicat între diferite puncte într-o rețea. O bază de date de programare orientat-obiect este unul care este congruent cu datele definite în clase de obiecte și subclase.

Baze de date informatice contin de obicei agregate de înregistrări de date sau fișiere, cum ar fi tranzacțiile de vânzare, cataloage de produse si stocuri, și profile de client. De obicei, un manager de baze de date oferă utilizatorilor capacitățile de control acces de citire / scriere, precizând generarea de rapoarte, și analiza de utilizare. Baze de date și manageri de baze de date sunt predominante în sistemele mainframe mari, dar sunt de asemenea prezente în sistemele mai mici stații de lucru și mid-range distribuite, cum ar fi AS / 400 și de pe computerele personale. SQL (Structured Query Language) este un limbaj standard pentru a face interogări interactive de la o bază de date și actualizarea cum ar fi DB2 IBM, Microsoft SQL Server, iar produsele de baze de date de la Oracle, Sybase, și Computer Associates.

Cel mai răspândit tip de baze de date este tipul relațional, în care datele sunt memorate în tabele si sunt legate intre ele cu chei de legatura. 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.

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

4.1. Inițializare, contextul

In general, scopul multor calculatoare este acela de a prelua informatii dintr-o anumita locatie, de a o prelucra dupa criteriile definite de client si in cele din urma, de a o returna utilizatorului. Dupa ce utilizatorul care foloseste aplicatia modifica continutul datelor si dupa aplicarea unor eventuale procesari ulterioare, sistemul schimba informatia cu una noua. Cea mai simpla metoda de a dezvolta o aplicatie care realizeaza aceste operatii este de unii si de a le trata ca pe un intreg. Aceasta metoda nu este o metoda recomandata insa este usor de realizat si pentru aplicatiile simple inca se utilizeaza. Dupa aceea apar insa probleme cand se vrea schimbarea uneia din componentele fluxului de date, un exemplu ar fi atunci cand se doreste inlocuirea interfetei de utilizator. O alta problema este logica aplicatiei care si ea este supusa modificarilor ulterioare si care merge dincolo de simpla inlocuire de informatie intr-un sistem automatizat.

4.2. Problema flexibilitatii si testabilitatii.

Apare asadar nevoia de a modulariza,sperara pe concepte aplicatia, de a delimita in mod clar partile componente spre a putea fi usor inlocuite si ca dupa modificare sa fie inca compatibile cu celelalte module ce compun 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 flexibilitatii si testabilitatii

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

Avem asadar trei entitati diferite:

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.

View-ul transpune model-ul intr-o forma mai usoara, in mod normal este o interfata vizuala la aplicatiile web este un fisier cu extensia html. Pot exista mai multe view-uri pentru un singur model si acest model sa fie folosit pentru scopuri total diferite.

Controller-ul primeste un eveniment de la utilizator si retirneaza un raspuns in urma cererilor catre obiectele model. Controller-ul este cel care controleaza celelalte doua tipuri de obiecte, view si model, obligandu-le sa execute tranzactii pe baza input-ului primit de la pe intrefata de utilizator.

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

4.4. Scurt Istoric

Arhitectura MVC nu este o arhitectura noue ea a fost descris pentru prima oara in 1979 de catre Trygve Reenskaug care pe vremea aceea lucra la Smalltalk din cadrul Xerox PARC insa a durat destul de mult pana s-a ajuns la implementarea ei la scara de productie.

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 arhitectura MVC

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 de obicei codul HTML generat de aplicatie. Controller-ul primeste variabile prin protocolul HTTP sau HTTPS de tip GET si POST ca si date de intrare si decide ce trebuie sa faca cu acestea prelund si sarcina de logica a aplicatiei, trimitand datele mai departe model-ului. Model-ul, mentine datele intr-un format care sa poata fi accesat in view insa care poate contine logica de business si regulile aferente, poate efectua operatiile necesare asupra datelor pentru a putea permite aplicatiei generarea codului . Model-ul nu este neaparat doar o baza de date ci pentru unii dezvoltatori 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 si usor de interpretat. Arhitectura MVC nu specifica in mod explicit nivel de acces la date dar se deduce ca ar fi incapsulat in model. In aplicatii simple care nu au multe reguli de business , model-ul se poate limita doar la accesarea unei baza de date si la operatiunile oferite de aceasta.

Controller-ul este confundat de multe ori cu aplicatia, pe cand scopul sau principal este de a dirija input-urile intre view si model. Se intalneste cazul in care datele afisate/adunate de la utilizator difera foarte mult structura bazei de date. Aceste diferente apar datorita conversiilor ce pot fi aplicate asupra datelor de catre controller pentru a ajuta traficul de date intre clase. Fiecare conceput are anumite asteptari definite in ceea ce priveste structura datelor, sau aceste transformari de structura trebuiesc realizate automat pentru a mentine un flux constant asigurand aplicatia ca fiecare modul primeste formatul de date asteptat. Asta pe langa functia de baza de controla traficul de cereri intre module. View-ul, este interpretat adeseori ca fiind limitat doar la expunerea informatiei intr-un anumit format insa view-ul are un rol important si in interactiunea cu utilizatorul. In exemplul de mai sus al aplicatiilor web interfata generata in format html este cea care nu se ocupa doar de afisarea informatiilor ci si de preluarea datele primite si de masurile luate pentru ca acesta sa fie corect.

4.7. Functionare aplicatie .

Fluxul unei aplicatii dezvoltate dupa arhitectura MVC decurge, in linii mari, in felul urmator:

Userul interactioneaza cu interfata. (exemplu: apasa un buton la tastatura sau face click pe un buton,link)

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

Controller-ul instiinteaza model-ul de actiunea utilizatorului, dupa care urmeaza de obicei o schimbare a starii model-ului. (un exemplu ar fi model-ul reimprospateaza starea campului de data inregistrare)

View-ul interogheaza model-ul pentru a genera o interfata corespunzatoare ca si exemplu view-ul afiseaza noua data deinregistrare alaturi de un buton de confirmare)

Interfata asteapta evenimente din partea utilizatorului, fuxul reluandu-se de cate ori este nevoie.

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

In folderul App avem structurat pe fisiere codul pentru angular impartit pe controler, directive, servicii,rutarea aplicatie.Cu ajutorul librariei de angular putem accesa de pe client metode de pe partea de server care pot fi gasite in folderul Controllers in clasele de tip controller care sa faca diverse operatiuni de validare, intergoare baza de date prin business.

In folderul App_Data amintim clasa NinjectWebCommon.cs care ne ajuta la rezolvarea dependentelor pentru repository prin metoda injectare de dependinte.Pentru a avea aceasta clasa trebuie instalat pachetul Ninject.

In directorul de content avem definite fisierele de stil css iar in Controllers sunt definite controalele aplicatiei.In Models sunt definite modele pentru view, in Scripts librariile javascript.In Templates sunt structurate view-rile pentru angular si in ultimul folder sunt view-rile pentru aplicatia noastra.In fisierul Web.config sunt definite configurarile pentru aplicatie.Acest nivel este unul foarte important si este bine sa fie structurat pentru o gestiune mai buna.

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.Prin abstractizarea accesului la DAL testabilitatea se poate face cu usurinta cu date fictive fara a accesa fizic baza de date si in al doilea rand permite schimbarea nivelului de accesa la date fara a modifica logica aplicatiei deci refolosirea codului.In directorul BusinessObject avem definite entitati ca si IncomeBusinessObject, ExpenseBusinessObject, sintaxa fiind numele modeluiui pe care il reprezinta si BusinessObject.

Fig. 11

Nivelul de acces al bazei de date este locul unde avem implementat un repository pattern cu ajutorul unei clase de baza abstracta numita GenericRepozitory<C,T> care implementeaza interfata IGenericRepozitory<T> si primeste ca parametri generici un obiect de instanta care reprezinta entitatea asupra carea se aplica modelul iar al doilea parametru este de tip DbContext.

Fig 1.1

GenericRepository are un constructor si primeste ca parametru un DbContext si seteaza un camp privat de Dbcontext, acest camp se numeste _entities si are o proprietatea Context pentru a putea fi accesata ulterior.Clasa mai contine si metodele virtuale Add,Delete,Edit,SaveGetAll implementate cu ajutorul Entity si Linq.Cu ajutorul IQueryable s-a implementat metoda FindBy care primeste ca parametru o functie pentru a specifica criteriul de cautare.Ca si metoda abstracta care va trebui implementata obligatoriu in clasele derivate avem metoda GetById care primeste un parametru de tip int.Structura se poate vedea in figura urmatoare.

Intergata IGenericRepository<T> are un parametru generic prin care se trimite tipul entitatii asupra caruia se vor aplica metodele Add,Delete,Edit,Save,GetAll,FindBy, si GetById.

In directorul Repositories avem doua noi directoare numite Impementations si Interfaces.In primul sunt definite clasele concrete care implementeaza repository pentru o entitate iar in directorul Interfaces sunt definite metodele care trebuiesc implementate de clasa concreta.

Un model de repository implementat este cel pentru venituri numit IncomeRepository si care se afla in directorul Implementation.Aceasta clasa mosteneste din clasa abstracta GenericRepository si trimite ca parametru ApplicationDbContext care este contextul aplicatie si entitatea Income.Aceasta mai implementeaza si interfata IIncomeRepository definita in directorul Interfaces. IncomeRepository are un constructor privat care primeste ca parametru un AplicationDbContext care mosteneste din IdentityDbContext<T> care vine din EntityFramework si implementeaza o interfata numita IDbContext.

Atunci cand implementam un nou repository si derivam din GenericRepository<C,T> trebuie sa impementam metoda abstracta GetById si metodele definite in interfata asociata.Un exemplu se poate vedea in figura x.

Iar intertata implementata de acest repository este:

Pentru a scrie o interogare care sa aduca un venit care are un id stiut de noi este foarte usor dupa cum se poate vedea in figura a. Accesand proprietatea Context definita in clasa abstracta GenericRepository se acceseaza entitatea DbSet<Income> Income. DbSet este o colectie cu toate entitatile din context si pot interoga baza de date specificand un tip.Obiectele DbSet sunt create dintr-un DbContext folosind metoda DbContext.Set(). Metoda de extensie Where de tip IQueryable permite scrierea interogarii pentru un tip cunoscut si accepta o expresie logica pentru filtrarea rezultatelor.First() este o metoda statica care returneaza primul elemet care respecta conditia de filtrare,daca nu este specificata expresia lamda atunci returneaza primul element din lista de rezultate.

Fig. 11

Nivelul de model este nivelul unde avem folderele DbContexts,Enums,ViewModels si entitatile ca Income, Expense etc.

Fig.11

In directorul Enums avem definite tipurile enum pentru o organizare mai buna, in ViewModels avem modelele care sunt folosite pentru afisarea datelor pe interfata de utilizator.In acest nivel nu avem logica pentru aplicatia noastra si nici interogari ale bazei de date, acest nivel este folosit pentru a pastra modelele intr-un sigur loc, curat si accesibil in celelalte nivele.

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