Filosofii de abordare a implementării
abordarea cascadei
Abordarea în cascadă a implementării unei aplicații necesită ca proiectantul să se consulte cu unul sau mai mulți reprezentanți ai organizației utilizatorului final și să noteze toate specificațiile aplicației. De obicei, specificațiile vin într-un set de documente funcționale sau cazuri de utilizare, scrise în așa fel încât utilizatorul final să poată citi și înțelege cu ușurință documentele.
Utilizatorul final semnează aceste documente, iar documentele sunt apoi colectate de echipa de proiectare tehnică care proiectează aplicația, creând diverse artefacte, cum ar fi diagrame de model de clasă, diagrame de stare, diagrame de activitate și modele de date. Scopul acestei faze este de a scrie totul atât de detaliat încât un dezvoltator nu va avea probleme în a crea codul necesar. Există o predare oficială a designului către echipa de dezvoltare și către echipa de testare. După livrare, echipa de dezvoltare începe codificarea, iar echipa de testare utilizează designul tehnic în combinație cu cazurile de utilizare pentru a crea cazuri de testare și scenarii de testare.
După ce echipa de dezvoltare termină codificarea, codul este predat echipei de testare. Echipa de testare efectuează testele pe care le-a proiectat pe baza cerințelor și a designului detaliat. Orice problemă va fi rezolvată de echipa de dezvoltare. Odată ce procesul de testare și reparare este finalizat, aplicația este livrată utilizatorului final pentru testarea de acceptare. Utilizatorul final efectuează o verificare finală pentru a vedea dacă aplicația respectă cerințele inițiale. Dacă este aprobat, el aprobă produsul finit și proiectul este finalizat. După ce echipa de dezvoltare termină codificarea, codul este predat echipei de testare.
Echipa de testare efectuează testele pe care le-a proiectat pe baza cerințelor și a designului detaliat. Orice problemă va fi rezolvată de echipa de dezvoltare. Odată ce procesul de testare și reparare este finalizat, aplicația este livrată utilizatorului final pentru testarea de acceptare. Utilizatorul final efectuează o verificare finală pentru a vedea dacă aplicația respectă cerințele inițiale. Dacă este aprobat, el aprobă produsul finit și proiectul este finalizat. După ce echipa de dezvoltare termină codificarea, codul este predat echipei de testare. Echipa de testare efectuează testele pe care le-a proiectat pe baza cerințelor și a designului detaliat.
Orice problemă va fi rezolvată de echipa de dezvoltare. Odată ce procesul de testare și reparare este finalizat, aplicația este livrată utilizatorului final pentru testarea de acceptare. Utilizatorul final efectuează o verificare finală pentru a vedea dacă aplicația respectă cerințele inițiale. Dacă este aprobat, el aprobă produsul finit și proiectul este finalizat.
Utilizatorul final efectuează o verificare finală pentru a vedea dacă aplicația respectă cerințele inițiale. Dacă este aprobat, el aprobă produsul finit și proiectul este finalizat. Utilizatorul final efectuează o verificare finală pentru a vedea dacă aplicația respectă cerințele inițiale. Dacă este aprobat, el aprobă produsul finit și proiectul este finalizat.
Un proiect poate avea mai multe sau mai puține faze atunci când se utilizează abordarea în cascadă, dar caracteristica cheie este un început și un sfârșit foarte formal al fiecărei faze, cu livrabile foarte formale.
Avantajul abordării cu cascadă este că responsabilitatea echipei responsabile pentru fiecare fază este mai mare. Este clar ce trebuie să livreze, când trebuie să-l livreze și cui trebuie să-l livreze. Adesea, echipa de dezvoltare nu va trebui să interacționeze cu utilizatorul. Acest lucru poate fi foarte util atunci când externalizați dezvoltarea într-o altă țară.
Principalul dezavantaj al abordării cu cascadă este că, într-un mediu în care totul este organizat într-un mod foarte formal, flexibilitatea de a răspunde la schimbări scade. Chiar și mutarea trebuie organizată. Foarte puține companii par să facă acest lucru în mod eficient, ducând adesea la o creștere semnificativă a costurilor generale. Pentru a gestiona costurile unui proiect, unele companii chiar amână orice modificare a cerințelor până la livrarea inițială a aplicației, livrând efectiv o aplicație care nu satisface nevoile utilizatorului final.
dezvoltare agila
Multe proiecte de dezvoltare software de lungă durată au depășit bugetul și nu au livrat produsul la timp. Premisa filozofiei agile de dezvoltare a software-ului este de a minimiza riscul prin dezvoltarea de software în casete de timp scurt, numite iterații, care durează de obicei de la una până la patru săptămâni. Fiecare iterație este ca propriul proiect software în miniatură și include toate sarcinile necesare pentru a lansa creșterea noilor funcționalități: planificare, analiza cerințelor, proiectare, codificare, testare și documentare. Deși este posibil ca o iterație să nu adauge suficientă funcționalitate pentru a garanta lansarea produsului, un proiect software agil își propune să poată lansa software nou la sfârșitul fiecărei iterații. La sfârșitul fiecărei iterații, echipa reevaluează prioritățile proiectului.
Scopul dezvoltării agile de software este de a atinge satisfacția clienților prin livrarea rapidă și continuă a software-ului util; urmărind întotdeauna să construiască ceea ce are nevoie clientul; salută, mai degrabă decât să se opună, modificările târzii ale cerințelor; se adaptează în mod regulat la circumstanțe în schimbare; să existe o cooperare strânsă și zilnică între antreprenori și dezvoltatori, în care conversația față în față este cea mai bună formă de comunicare.
Principalul avantaj al dezvoltării agile de software este flexibilitatea în a face față schimbărilor, urmărind întotdeauna livrarea în funcție de nevoile afacerii. Dezavantajul, desigur, este o creștere a complexității gestionării domeniului de aplicare, a planificării și a bugetării. Un alt risc comun este atenția limitată acordată documentației (tehnice).
Dezvoltare incrementală
Dezvoltarea software incrementală este o combinație de dezvoltare agilă și în cascadă. O aplicație este proiectată, implementată și testată în mod incremental, astfel încât fiecare increment să poată fi livrat utilizatorului final. Proiectul nu este finalizat până la finalizarea ultimului increment. Acesta își propune să scurteze cascada prin definirea unor incremente intermediare și folosind unele dintre avantajele dezvoltării agile. Pe baza feedback-ului primit cu privire la o creștere anterioară, pot fi făcute ajustări la livrarea următoarei creșteri. Următorul increment poate consta din cod nou, precum și modificări ale codului furnizat anterior.
Avantajul este că formalitățile rămân în vigoare, dar managementul schimbării devine mai ușor. Costul testării și implementării unei aplicații de mai multe ori va fi mai mare decât a face o singură dată.
Controlul fluxului programului
Alegerea unei abordări pentru controlul fluxului de programe este o sarcină foarte arhitecturală. Scopul este de a crea un plan al aplicației dvs. în care, odată ce începeți să adăugați funcționalitate și cod, totul pare să aibă propriul loc. Dacă ați revizuit sau ați scris vreodată cod de înaltă calitate, înțelegeți acest principiu.
Cod organizator
Primul pas în proiectarea fluxului de program este organizarea codului prin stabilirea unui set de reguli care să ajute la crearea unui plan sau schiță a aplicației. Întreținerea, depanarea și remedierea erorilor vor fi mai ușoare, deoarece codul se află într-o locație logică. După ce ați făcut lucrările de bază, puteți alege o abordare pentru implementarea logicii aplicației dvs.
Modelele de proiectare ar trebui să joace un rol important în proiectarea controlului fluxului de programe. De-a lungul anilor, s-a scris mult cod și au fost concepute multe soluții pentru probleme recurente. Aceste soluții sunt prezentate în modele de design. Aplicarea unui model de design la o problemă comună de proiectare software vă va ajuta să creați soluții care sunt ușor de recunoscut și care pot fi implementate de colegii dvs. Problemele unice vor necesita în continuare soluții unice, dar puteți folosi modele de design pentru a vă ghida în rezolvarea lor.
Crearea Proiectului
straturi
Primul pas este să luați în considerare straturile logice. Rețineți că straturile nu sunt la fel cu straturile, adesea confundate sau chiar considerate la fel.
straturi versus straturi
Straturile se referă la crearea de limite în codul dvs. Stratul superior poate avea referințe la cod în straturile de mai jos, dar un strat nu poate avea niciodată o referință la cod într-un strat de deasupra. Nivelurile se referă la distribuția fizică a nivelurilor pe mai multe computere. De exemplu, într-o aplicație cu trei niveluri, interfața de utilizare este proiectată să ruleze pe un computer desktop, logica aplicației este proiectată să ruleze pe un server de aplicații, iar baza de date rulează pe un server de date dedicate și codul din fiecare stratul poate consta din mai multe straturi.
Figura 8-1: Organizarea de bază pe trei niveluri
Straturile se referă la niveluri de abstractizare. Straturile prezentate în Figura 8-1 sunt valabile pentru majoritatea aplicațiilor. Aceste niveluri sunt denumite și cele trei straturi principale și pot avea diverse alte nume. De regulă, codul din stratul de prezentare poate apela servicii din stratul logic al aplicației, dar stratul logic al aplicației nu trebuie să apeleze metoda din stratul de prezentare. Nivelul de prezentare nu ar trebui să apeleze în mod direct stratul de acces la date, deoarece acest lucru ar ocoli responsabilitățile implementate de stratul logic al aplicației. Stratul de acces la date nu ar trebui să apeleze niciodată stratul logic al aplicației.
Straturile sunt doar o abstractizare și, probabil, cea mai ușoară modalitate de a implementa straturi este să creați foldere în proiectul dvs. și să adăugați cod în folderul corespunzător. O abordare mai utilă ar fi plasarea fiecărui strat într-un proiect separat, creând astfel ansambluri separate. Avantajul punerii logicii aplicației într-un ansamblu de bibliotecă este că vă va permite să creați teste unitare, folosind Microsoft Visual Studio sau NUnit, pentru a testa logica. De asemenea, creează flexibilitate în alegerea locului în care să implementați fiecare strat.
Straturi fizice
Într-o aplicație de întreprindere, v-ați aștepta să aveți mai mulți clienți pentru aceeași logică. De fapt, ceea ce face ca o aplicație să fie o aplicație de întreprindere este că va fi implementată în trei straturi: client, server de aplicații și server de baze de date. Aplicația Microsoft Office Access creată de departamentul de vânzări al companiei dvs., deși foarte importantă pentru departamentul de vânzări, nu este o aplicație corporativă.
Rețineți că logica aplicației și straturile de acces la date sunt adesea implementate împreună pe serverul de aplicații. O parte din proiectarea proiectului este alegerea dacă să accesați serverul de aplicații folosind .NET la distanță sau servicii Web. Indiferent ce alegeți, veți adăuga un cod pentru a accesa cu ușurință serviciile de la distanță în stratul de prezentare. Dacă utilizați servicii web pentru a accesa serviciile de pe serverul dvs. de aplicații, Visual Studio .NET va face treaba pentru dvs. și va genera codul proxy, oferind automat o implementare a modelului proxy la distanță.
Adăugarea de modele la straturi
Cele trei straturi de bază oferă o imagine de ansamblu la nivel înalt. Să adăugăm câteva modele structurale pentru a crea o arhitectură de întreprindere robustă. Rezultatul este prezentat în Figura 8-2.
Concentrați-vă pe stratul logic al aplicației. Figura 8-2 arată că accesarea logicii aplicației folosește modelul de fațadă. O fațadă este un obiect care oferă o interfață simplificată unui corp mai mare de cod, cum ar fi o bibliotecă de clase. O fațadă poate reduce dependențele de cod extern de funcționarea interioară a unei biblioteci, deoarece majoritatea codului utilizează fațada, permițând astfel mai multă flexibilitate în dezvoltarea sistemului. Pentru a face acest lucru, fațada va oferi o interfață cu granulație grosieră unei colecții de obiecte cu granulație fină.
flux de decizie
Controlul fluxului de program, cunoscut și sub denumirea de flux de decizie, se referă la modul în care proiectați serviciile în stratul logic al aplicației sau, după cum ați văzut în paragraful anterior, modul în care proiectați metodele în fațadă.
Există două abordări pentru a vă organiza serviciile:
- orientate spre acțiune
- condus de stat
Abordare orientată spre acțiune
Prin organizarea serviciilor pe baza acțiunilor utilizatorului, implementați logica aplicației oferind servicii, fiecare dintre ele gestionând o anumită solicitare din nivelul de prezentare. Acesta este, de asemenea, cunoscut sub numele de model de script de tranzacție. Această abordare este populară deoarece este simplă și arată foarte naturală. Exemple de metode care urmează această abordare sunt BookStoreService.AddNewOrder(Order order) și BookStoreService.CancelOrder(int orderId).
Logica necesară pentru a efectua acțiunea este implementată foarte secvențial în cadrul metodei, făcând codul foarte lizibil, dar și mai greu de reutilizat. Utilizarea modelelor de design suplimentare, cum ar fi modelul modulului de masă, poate ajuta la creșterea reutilizabilității.
Abordare condusă de stat
De asemenea, este posibilă implementarea fluxului de decizie al aplicației într-un mod mult mai orientat spre stat. Serviciile oferite de serverul de aplicații sunt de natură mai generică, de exemplu BookStoreService.SaveOrder(Order order). Această metodă va examina starea comenzii și va decide dacă adăugați o nouă comandă sau anulați o comandă existentă.
Proiecte de structura de date
Trebuie să faceți mai multe alegeri atunci când vă proiectați structurile de date. Prima alegere este mecanismul de stocare a datelor, a doua este utilizarea prevăzută a datelor, iar a treia este cerințele versiunii. Există trei moduri de a privi proiectele structurii de date:
- Serviciile oferă date; datele sunt o reflectare a bazei de date relaționale.
- Datele trebuie mapate la obiecte, iar serviciile oferă acces la obiecte.
- Datele oferite de servicii trebuie să fie bazate pe scheme.
Alegerea uneia dintre cele trei ca bază pentru structura fluxului de date ar trebui făcută într-un stadiu incipient al procesului de proiectare. Multe companii au un ghid al companiei care impune una dintre cele trei opțiuni pentru toate proiectele, dar acolo unde este posibil, ar trebui să reevaluați opțiunile pentru fiecare proiect, alegând abordarea optimă pentru proiectul în cauză.
Alegerea unui motor de stocare a datelor
Când vă proiectați aplicația, va trebui, fără îndoială, să proiectați un fel de depozit de date. Sunt disponibile următoarele magazine și forme de stocare a datelor:
- Record
- fișierul app.config
- fișiere xml
- fișiere text simplu
- Bază de date
- aşteptarea mesajelor
Fiecare magazin are propriile sale caracteristici unice și poate fi adaptat la cerințe specifice.
Proiectarea fluxului de date
Fluxul de date folosind ADO.NET
Prin implementarea serviciilor centrate pe date în stratul logic al aplicației, vă veți proiecta fluxul de date folosind ADO.NET. Biblioteca de clase .NET Framework oferă o interfață extinsă de programare a aplicațiilor (API) pentru manipularea datelor în cod gestionat. Denumit ADO.NET, API-ul poate fi găsit în spațiul de nume System.Data. Separarea completă a suporturilor de date și a depozitelor de date este o caracteristică importantă de proiectare a ADO.NET. Clase precum DataSet, DataTable și DataRow sunt concepute pentru a stoca date, dar nu păstrează cunoștințele de unde provin datele. Sunt considerate agnostice ale surselor de date. Un set separat de clase, cum ar fi SqlConnection, SqlDataAdapter și SqlCommand, se ocupă de conectarea la o sursă de date, de preluarea datelor și de popularea DataSet, DataTable și DataRow. Aceste clase sunt situate în sub-spații de nume precum System.Data.Sql, System.Data.OleDB, System.Data.Oracle și așa mai departe. În funcție de sursa de date la care doriți să vă conectați, puteți utiliza clase în spațiul de nume potrivit și, în funcție de domeniul de aplicare al produsului pe care îl utilizați, veți descoperi că aceste clase oferă mai mult sau mai puține funcționalități.
Deoarece DataSet-ul nu este conectat la sursa de date, acesta poate fi folosit cu succes pentru a gestiona fluxul de date într-o aplicație. Figura 8-5 arată fluxul de date atunci când faceți acest lucru.
Să aruncăm o privire la acest proiect și să ne imaginăm că cineva s-a autentificat în librăria ta și a comandat trei cărți. Stratul de prezentare gestiona starea coșului de cumpărături. Clientul este gata să plaseze comanda și a furnizat toate datele necesare. El alege să trimită comanda. Pagina web transformă toate datele într-un DataSet care conține două DataTable, unul pentru comandă și unul pentru comandă; inserează un DataRow pentru comandă; și inserează trei DataRows pentru liniile de comandă. Pagina web afișează apoi aceste date înapoi utilizatorului încă o dată, legând controalele datelor cu DataSet și întrebând Sunteți sigur? Utilizatorul confirmă cererea și este trimisă la nivelul logic al aplicației. Stratul logic al aplicației verifică DataSet-ul pentru a vedea dacă toate câmpurile obligatorii au o valoare și efectuează o verificare pentru a vedea dacă utilizatorul are mai mult de 1000 US$. 00 pentru facturile restante. Dacă totul merge bine, DataSet-ul este trecut la nivelul de acces la date, care se conectează la baza de date și generează instrucțiuni de inserare din informațiile DataSet.
Utilizarea DataSet-ului în acest mod este o modalitate rapidă și eficientă de a construi o aplicație și de a utiliza puterea Bibliotecii de clasă Framework și capacitatea ASP.NET de a lega date la diferite controale, cum ar fi GridView cu un DataSet. În loc să utilizați obiecte DataSet simple, puteți utiliza obiecte Typed DataSet și puteți îmbunătăți experiența de codare prin implementarea codului în stratul de prezentare, precum și în stratul logic al aplicației. Avantajul acestei abordări este și dezavantajul abordării. Micile modificări ale modelului de date nu duc neapărat la multe metode care trebuie să-și schimbe semnăturile. Deci, în ceea ce privește întreținerea, aceasta funcționează foarte bine. Dacă vă amintiți că stratul de prezentare nu este neapărat o interfață de utilizator, poate fi și un serviciu web. Și dacă modificați definiția DataSet-ului, poate pentru că redenumiti un câmp din baza de date, atunci modificați contractul la care este abonat serviciul web. După cum vă puteți imagina, acest lucru poate duce la unele probleme semnificative. Acest scenariu funcționează bine dacă stratul de prezentare este doar o interfață cu utilizatorul, dar pentru interfețele către sisteme sau componente externe, veți dori să ascundeți funcționarea interioară a aplicației dvs. și să transformați datele în altceva decât o clonă directă a modelului dvs. de date și veți dori să creați obiecte de transfer de date (DTO).
Fluxul de date folosind maparea relațională obiect
Fluxul de date folosind ADO.NET este o abordare foarte centrată pe date pentru gestionarea fluxului de date. Datele și logica sunt discrete. Celălalt capăt al spectrului adoptă o abordare mai orientată pe obiecte. Aici, clasele sunt create pentru a grupa datele și comportamentul. Scopul este de a defini clase care imită datele și comportamentul găsit în domeniul de afaceri pentru care a fost creată aplicația. Rezultatul este adesea denumit obiect de afaceri. Colecția de obiecte de afaceri care alcătuiesc aplicația se numește model de domeniu. Unii dezvoltatori susțin că un model de domeniu bogat este mai bun pentru proiectarea unei logici mai complexe. Este dificil să dovedești sau să infirmi o astfel de afirmație. Doar să știi că ai de ales și depinde de tine să o faci.
Figura 8-6 prezintă un flux de date similar cu Figura 8-5, cu excepția faptului că acum ați adăugat stratul de mapare relațională a obiectelor și ați înlocuit obiectele DataSet cu diferiți purtători de date.
Acum faceți același pas cu pas ca înainte; imaginați-vă că cineva s-a conectat la librăria dvs. și a comandat trei cărți. Stratul de prezentare gestiona starea coșului de cumpărături. Clientul este gata să plaseze comanda și a furnizat toate datele necesare. El alege să trimită comanda. Pagina web transformă toate datele într-un DTO, deținând date pentru o comandă și cu trei linii de comandă, creând obiectele după cum este necesar. Pagina web afișează aceste date înapoi utilizatorului încă o dată, controalele de legare a datelor împotriva DTO folosind ObjectDataSource în ASP.NET 2.0 și întreabă Ești sigur? Utilizatorul confirmă alegerea și DTO este trimis la stratul logic al aplicației. Stratul logic al aplicației transformă DTO într-un obiect de afaceri de tip Order cu o proprietate care să conțină trei obiecte OrderLine. Metoda Comanda. Validate() este apelat pentru a valida comanda și a verifica dacă toate câmpurile obligatorii au o valoare și se face o verificare pentru a identifica dacă utilizatorul are mai mult de R$ 1.000,00 în fișele în așteptare. Pentru a face acest lucru, comanda va apela Order.Customer.GetOutstandingBills(). Dacă totul este bine, se apelează metoda Order.Save(). Solicitarea va trece prin stratul de mapare relațională a obiectelor, unde cererea și rândurile cererii sunt mapate la un DataTable dintr-un DataSet, iar DataSet-ul este trecut la stratul de acces la date, care se conectează la baza de date și generează instrucțiuni de inserare din informațiile din DataSet. Există, desigur, multe moduri în care poate apărea maparea obiect-relațională, dar nu toate vor include transformarea într-un DataSet. Unii vor crea direct instrucțiunea de inserare, dar totuși vor folosi stratul de acces la date pentru a executa acea instrucțiune.
După cum puteți vedea, au loc unele transformări. Utilizarea DTO-urilor este necesară deoarece un obiect de afaceri implementează comportamentul, iar comportamentul este supus modificării. Pentru a minimiza impactul acestor modificări asupra stratului de prezentare, trebuie să transformați datele din obiectul de afaceri într-un obiect de transfer de date. În Java, obiectul de transfer de date este adesea denumit obiect de valoare.
Un mare avantaj al lucrului cu obiecte de afaceri este că vă ajută cu adevărat să vă organizați codul. Dacă te uiți înapoi la o bucată complexă de logică, de obicei este foarte lizibilă, deoarece există foarte puțin cod de instalații. Dezavantajul este că majoritatea depozitelor de date sunt încă relaționale, iar maparea obiectelor de afaceri cu datele relaționale poate deveni destul de complexă.
servicii bazate pe scheme
Tocmai ați văzut două opuse când vine vorba de gestionarea fluxului de date. Sunt posibile multe variante. Una obișnuită este varianta în care un set de date este utilizat ca suport de date de bază al interfeței de utilizare pentru stocarea datelor, dar schemele separate (DTO) sunt folosite pentru serviciile web apelate de la alte sisteme. Stratul de aplicație transformă datele relaționale într-o schemă predefinită. Principalul avantaj al acestui lucru este că orice aplicație care face referire la serviciu nu depinde de niciun fel de implementare internă a componentei. Acest lucru permite mai multă flexibilitate în versiunea, compatibilitatea inversă a interfețelor și capacitatea de a schimba implementarea componentei fără a schimba interfața serviciului.
Desigur, puteți utiliza obiecte de afaceri în aplicația web și puteți ocoli transformarea DTO, dar aceasta funcționează de obicei bine numai dacă logica aplicației este implementată împreună cu aplicația web. Amintiți-vă că pentru a apela Order.Save() veți avea nevoie de o conexiune la baza de date. Dacă acest lucru este de dorit, depinde de tine și probabil directorul tău de securitate.