Filozofije pristupa implementaciji
pristup vodopadu
Vodopadni pristup implementaciji aplikacije zahtijeva da se dizajner konzultira s jednim ili više predstavnika organizacije krajnjeg korisnika i zapiše sve specifikacije aplikacije. Tipično, specifikacije dolaze u skupu funkcionalnih dokumenata ili slučajeva upotrebe, napisanih na takav način da krajnji korisnik može lako pročitati i razumjeti dokumente.
Krajnji korisnik potpisuje te dokumente, a dokumente zatim prikuplja tehnički dizajnerski tim koji dizajnira aplikaciju, stvarajući razne artefakte kao što su dijagrami modela klasa, dijagrami stanja, dijagrami aktivnosti i modeli podataka. Cilj ove faze je napisati sve tako detaljno da programer neće imati problema sa kreiranjem potrebnog koda. Postoji formalna primopredaja dizajna razvojnom timu i timu za testiranje. Nakon isporuke, razvojni tim počinje s kodiranjem, a testni tim koristi tehnički dizajn u kombinaciji sa slučajevima upotrebe za izradu testnih slučajeva i testnih scenarija.
Nakon što razvojni tim završi kodiranje, kod se predaje testnom timu. Testni tim provodi testove koje je osmislio na temelju zahtjeva i detaljnog dizajna. Sve probleme riješit će razvojni tim. Nakon završetka procesa testiranja i popravka, aplikacija se isporučuje krajnjem korisniku na testiranje prihvaćanja. Krajnji korisnik provodi završnu provjeru da vidi je li aplikacija u skladu s početnim zahtjevima. Ako je odobren, on odobrava gotov proizvod i projekt je dovršen. Nakon što razvojni tim završi kodiranje, kod se predaje testnom timu.
Testni tim provodi testove koje je osmislio na temelju zahtjeva i detaljnog dizajna. Sve probleme riješit će razvojni tim. Nakon završetka procesa testiranja i popravka, aplikacija se isporučuje krajnjem korisniku na testiranje prihvaćanja. Krajnji korisnik provodi završnu provjeru da vidi je li aplikacija u skladu s početnim zahtjevima. Ako je odobren, on odobrava gotov proizvod i projekt je dovršen. Nakon što razvojni tim završi kodiranje, kod se predaje testnom timu. Testni tim provodi testove koje je osmislio na temelju zahtjeva i detaljnog dizajna.
Sve probleme riješit će razvojni tim. Nakon završetka procesa testiranja i popravka, aplikacija se isporučuje krajnjem korisniku na testiranje prihvaćanja. Krajnji korisnik provodi završnu provjeru da vidi je li aplikacija u skladu s početnim zahtjevima. Ako je odobren, on odobrava gotov proizvod i projekt je dovršen.
Krajnji korisnik provodi završnu provjeru da vidi je li aplikacija u skladu s početnim zahtjevima. Ako je odobren, on odobrava gotov proizvod i projekt je dovršen. Krajnji korisnik provodi završnu provjeru da vidi je li aplikacija u skladu s početnim zahtjevima. Ako je odobren, on odobrava gotov proizvod i projekt je dovršen.
Projekt može imati više ili manje faza kada se koristi pristup vodopada, ali ključna značajka je vrlo formalan početak i kraj svake faze, s vrlo formalnim rezultatima.
Prednost vodopadnog pristupa je veća odgovornost tima odgovornog za svaku fazu. Jasno je što trebaju isporučiti, kada to trebaju isporučiti i kome to trebaju isporučiti. Često razvojni tim neće morati komunicirati s korisnikom. Ovo može biti vrlo korisno kada se razvoj eksternalizira u drugoj zemlji.
Glavni nedostatak vodopada je taj što se u okruženju u kojem je sve organizirano na vrlo formalan način smanjuje fleksibilnost odgovora na promjene. Čak i selidbu treba organizirati. Čini se da vrlo malo tvrtki to čini učinkovito, što često rezultira značajnim povećanjem režijskih troškova. Kako bi upravljale troškovima projekta, neke tvrtke čak odgađaju sve promjene zahtjeva do početne isporuke aplikacije, učinkovito isporučujući aplikaciju koja ne zadovoljava potrebe krajnjeg korisnika.
agilni razvoj
Mnogi dugotrajni projekti razvoja softvera prekoračili su proračun i nisu isporučili proizvod na vrijeme. Pretpostavka filozofije agilnog razvoja softvera je minimiziranje rizika razvojem softvera u kratkim vremenskim okvirima, zvanim iteracije, koje obično traju od jednog do četiri tjedna. Svaka je iteracija poput vlastitog minijaturnog softverskog projekta i uključuje sve zadatke potrebne za izdavanje prirasta nove funkcionalnosti: planiranje, analizu zahtjeva, dizajn, kodiranje, testiranje i dokumentaciju. Iako iteracija možda neće dodati dovoljno funkcionalnosti da bi se opravdalo izdavanje proizvoda, cilj agilnog softverskog projekta je omogućiti izdavanje novog softvera na kraju svake iteracije. Na kraju svake iteracije, tim ponovno procjenjuje prioritete projekta.
Cilj agilnog razvoja softvera je postići zadovoljstvo korisnika brzom i kontinuiranom isporukom korisnog softvera; uvijek nastojeći izgraditi ono što kupac treba; pozdravljaju, umjesto da se protive, kasnim promjenama zahtjeva; redovito se prilagođavati promjenjivim okolnostima; imati blisku i svakodnevnu suradnju između poduzetnika i programera, u kojoj je razgovor licem u lice najbolji oblik komunikacije.
Glavna prednost agilnog razvoja softvera je fleksibilnost u suočavanju s promjenama, uvijek s ciljem isporuka u skladu s poslovnim potrebama. Loša strana je, naravno, povećanje složenosti upravljanja djelokrugom, planiranjem i proračunom. Još jedan uobičajeni rizik je ograničena pozornost na (tehničku) dokumentaciju.
Inkrementalni razvoj
Inkrementalni razvoj softvera je mješavina agilnog i vodopadnog razvoja. Aplikacija je dizajnirana, implementirana i testirana inkrementalno tako da se svaki inkrement može isporučiti krajnjem korisniku. Projekt nije dovršen sve dok se ne dovrši posljednji korak. Cilj mu je skratiti kaskadu definiranjem međuinkremenata i korištenjem nekih od prednosti agilnog razvoja. Na temelju povratnih informacija primljenih o prethodnom povećanju, mogu se napraviti prilagodbe prilikom isporuke sljedećeg povećanja. Sljedeći inkrement može se sastojati od novog koda kao i od izmjena prethodno dostavljenog koda.
Prednost je što formalnosti ostaju na snazi, ali upravljanje promjenama postaje lakše. Trošak testiranja i postavljanja aplikacije više puta bit će veći nego da se to radi samo jednom.
Kontrola tijeka programa
Odabir pristupa kontroli tijeka programa vrlo je arhitektonski zadatak. Cilj je stvoriti nacrt vaše aplikacije gdje će, nakon što počnete dodavati funkcionalnost i kod, sve izgledati kao da ima svoje mjesto. Ako ste ikada pregledali ili napisali visokokvalitetni kod, razumijete ovaj princip.
Kod organizatora
Prvi korak u dizajniranju toka programa je organiziranje koda uspostavljanjem skupa pravila koja će pomoći u stvaranju nacrta ili nacrta aplikacije. Održavanje, otklanjanje pogrešaka i ispravljanje pogrešaka bit će lakši jer se kod nalazi na logičnoj lokaciji. Nakon što napravite temelje, možete odabrati pristup implementaciji logike svoje aplikacije.
Uzorci dizajna trebali bi igrati važnu ulogu u dizajnu kontrole tijeka programa. Tijekom godina napisano je mnogo koda i osmišljena su mnoga rješenja za probleme koji se ponavljaju. Ta su rješenja postavljena u uzorcima dizajna. Primjena uzorka dizajna na uobičajeni problem dizajna softvera pomoći će vam da stvorite rješenja koja su lako prepoznatljiva i koja mogu implementirati vaši kolege. Jedinstveni problemi će i dalje zahtijevati jedinstvena rješenja, ali možete koristiti uzorke dizajna koji će vas voditi u njihovom rješavanju.
Izrada projekta
slojeva
Prvi korak je razmotriti logičke slojeve. Imajte na umu da slojevi nisu isto što i slojevi, često se miješaju ili čak smatraju istima.
slojevi protiv slojeva
Slojevi se bave stvaranjem granica u vašem kodu. Gornji sloj može imati reference na kod u slojevima ispod, ali sloj nikada ne može imati referencu na kod u sloju iznad. Razine se odnose na fizičku distribuciju razina na više računala. Na primjer, u troslojnoj aplikaciji, korisničko sučelje je dizajnirano za rad na stolnom računalu, logika aplikacije je dizajnirana za rad na aplikacijskom poslužitelju, a baza podataka radi na poslužitelju baze podataka. sloj se može sastojati od nekoliko slojeva.
Slika 8-1: Osnovna troslojna organizacija
Slojevi se odnose na razine apstrakcije. Slojevi prikazani na slici 8-1 vrijede za većinu aplikacija. Ove razine se također nazivaju tri glavna sloja i mogu imati različite druge nazive. U pravilu, kod u prezentacijskom sloju može pozivati usluge u aplikacijskom logičkom sloju, ali aplikacijski logički sloj ne smije pozivati metodu u prezentacijskom sloju. Prezentacijski sloj nikada ne bi trebao izravno pozivati sloj pristupa podacima, jer bi to zaobišlo odgovornosti koje implementira aplikacijski logički sloj. Sloj pristupa podacima nikada ne bi trebao pozivati sloj aplikacijske logike.
Slojevi su samo apstrakcija i vjerojatno je najlakši način za implementaciju slojeva stvaranje mapa u vašem projektu i dodavanje koda u odgovarajuću mapu. Korisniji pristup bio bi staviti svaki sloj u zaseban projekt, stvarajući tako zasebne sklopove. Prednost stavljanja vaše logike aplikacije u sklop biblioteke je u tome što će vam omogućiti stvaranje jediničnih testova, koristeći Microsoft Visual Studio ili NUnit, za testiranje logike. Također stvara fleksibilnost u odabiru mjesta za postavljanje svakog sloja.
Fizički slojevi
U poslovnoj aplikaciji očekivali biste da imate više klijenata za istu logiku. Zapravo, ono što aplikaciju čini poslovnom aplikacijom je to što će biti postavljena u tri sloja: klijent, aplikacijski poslužitelj i poslužitelj baze podataka. Aplikacija Microsoft Office Access koju je izradio odjel prodaje vaše tvrtke, iako je vrlo važna za odjel prodaje, nije korporativna aplikacija.
Imajte na umu da se aplikacijska logika i slojevi pristupa podacima često postavljaju zajedno na aplikacijskom poslužitelju. Dio dizajniranja projekta je odabir hoće li se pristupiti aplikacijskom poslužitelju pomoću udaljenih .NET ili web usluga. Što god odabrali, dodat ćeš neki kod za jednostavan pristup udaljenim uslugama u prezentacijskom sloju. Ako koristite web usluge za pristup uslugama na vašem aplikacijskom poslužitelju, Visual Studio .NET će obaviti posao umjesto vas i generirati proxy kod, automatski osiguravajući implementaciju uzorka udaljenog proxyja.
Dodavanje uzoraka slojevima
Tri osnovna sloja pružaju pregled na visokoj razini. Dodajmo neke strukturne obrasce kako bismo stvorili robusnu arhitekturu poduzeća. Rezultat je prikazan na slici 8-2.
Usredotočite se na sloj aplikacijske logike. Slika 8-2 pokazuje da pristup logici aplikacije koristi obrazac fasade. Fasada je objekt koji pruža pojednostavljeno sučelje većem tijelu koda, kao što je biblioteka klasa. Fasada može smanjiti vanjske ovisnosti koda o unutarnjem radu knjižnice jer većina koda koristi fasadu, čime se omogućuje veća fleksibilnost u razvoju sustava. Da bi se to postiglo, fasada će pružiti grubo zrnato sučelje zbirci fino zrnatih objekata.
tijek odluka
Kontrola tijeka programa, također poznata kao tijek odluka, odnosi se na to kako dizajnirate usluge u logičkom sloju aplikacije ili, kao što ste vidjeli u prethodnom odlomku, kako dizajnirate metode u svojoj fasadi.
Postoje dva pristupa organiziranju vaših usluga:
- usmjeren na akciju
- vođen državom
Pristup usmjeren na djelovanje
Organiziranjem usluga na temelju radnji korisnika implementirate logiku aplikacije nudeći usluge od kojih svaka obrađuje određeni zahtjev prezentacijskog sloja. Ovo je također poznato kao obrazac transakcijske skripte. Ovaj pristup je popularan jer je jednostavan i izgleda vrlo prirodno. Primjeri metoda koje slijede ovaj pristup su BookStoreService.AddNewOrder(Order order) i BookStoreService.CancelOrder(int orderId).
Logika potrebna za izvođenje radnje implementirana je vrlo sekvencijalno unutar metode, što kod čini vrlo čitljivim, ali ga je i teže ponovno koristiti. Korištenje dodatnih uzoraka dizajna, kao što je uzorak modula tablice, može pomoći u povećanju ponovne upotrebe.
Pristup vođen državom
Također je moguće implementirati tok odluke aplikacije na način koji je više orijentiran na stanje. Usluge koje nudi aplikacijski poslužitelj su više generičke prirode, na primjer BookStoreService.SaveOrder(Order order). Ova će metoda ispitati status narudžbe i odlučiti treba li dodati novu narudžbu ili poništiti postojeću narudžbu.
Projekti strukture podataka
Morate napraviti nekoliko izbora kada dizajnirate svoje strukture podataka. Prvi izbor je mehanizam za pohranjivanje podataka, drugi je namjeravana upotreba podataka, a treći su zahtjevi za verzijom. Postoje tri načina za promatranje dizajna strukture podataka:
- Usluge nude podatke; podaci su odraz relacijske baze podataka.
- Podaci se moraju preslikati na objekte, a usluge omogućuju pristup objektima.
- Podaci koje nude usluge moraju se temeljiti na shemi.
Odabir jednog od tri kao osnove za strukturu tijeka podataka trebao bi biti učinjen u ranoj fazi procesa dizajna. Mnoge tvrtke imaju smjernicu tvrtke koja nalaže jednu od tri opcije za sve projekte, ali gdje je to moguće, trebali biste ponovno procijeniti opcije za svaki projekt, birajući optimalan pristup za projekt koji je pri ruci.
Odabir mehanizma za pohranu podataka
Kada dizajnirate svoju aplikaciju, nedvojbeno ćete morati dizajnirati neku vrstu pohrane podataka. Dostupne su sljedeće trgovine i oblici pohrane podataka:
- Snimiti
- app.config datoteka
- xml datoteke
- obične tekstualne datoteke
- Baza podataka
- slanje poruka u red čekanja
Svaka trgovina ima svoje jedinstvene karakteristike i može se prilagoditi specifičnim zahtjevima.
Projektiranje protoka podataka
Protok podataka pomoću ADO.NET
Implementacijom usluga usmjerenih na podatke u logičkom sloju aplikacije, dizajnirat ćete svoj tok podataka koristeći ADO.NET. Knjižnica klasa .NET Framework pruža opsežno sučelje za programiranje aplikacija (API) za manipuliranje podacima u upravljanom kodu. Nazvan ADO.NET, API se može pronaći u prostoru imena System.Data. Potpuna odvojenost nositelja podataka i pohrana podataka važna je značajka dizajna ADO.NET-a. Klase poput DataSet, DataTable i DataRow dizajnirane su za pohranjivanje podataka, ali ne zadržavaju znanje o tome odakle su podaci došli. Smatraju se agnosticima izvora podataka. Zasebni skup klasa, kao što su SqlConnection, SqlDataAdapter i SqlCommand, brinu se o povezivanju s izvorom podataka, dohvaćanju podataka i popunjavanju DataSet-a, DataTable-a i DataRow-a. Te se klase nalaze u pod-imenskim prostorima kao što su System.Data.Sql, System.Data.OleDB, System.Data.Oracle i tako dalje. Ovisno o izvoru podataka na koji se želite povezati, možete koristiti klase u pravom imenskom prostoru, a ovisno o opsegu proizvoda koji koristite, vidjet ćete da te klase nude više ili manje funkcionalnosti.
Budući da DataSet nije povezan s izvorom podataka, može se prilično uspješno koristiti za upravljanje protokom podataka u aplikaciji. Slika 8-5 prikazuje tijek podataka kada se to radi.
Pogledajmo ovaj projekt i zamislimo da je netko ušao u vašu knjižaru i naručio tri knjige. Prezentacijski sloj upravlja stanjem košarice za kupnju. Kupac je spreman za narudžbu i dao je sve potrebne podatke. Odabire poslati narudžbu. Web stranica transformira sve podatke u DataSet koji sadrži dvije DataTables, jednu za red i jednu za red; umeće DataRow za narudžbu; i umeće tri podatkovna retka za retke narudžbe. Web-stranica zatim ponovo prikazuje te podatke natrag korisniku, povezujući kontrole podataka sa DataSet-om i pitajući Jeste li sigurni? Korisnik potvrđuje zahtjev i on se predaje logičkom sloju aplikacije. Logički sloj aplikacije provjerava DataSet da vidi imaju li sva potrebna polja vrijednost i provodi provjeru da vidi ima li korisnik više od 1000 US$. 00 na nepodmirene račune. Ako sve prođe dobro, DataSet se prosljeđuje sloju za pristup podacima, koji se povezuje s bazom podataka i generira izjave umetanja iz podataka DataSeta.
Korištenje DataSet-a na ovaj način je brz i učinkovit način za izradu aplikacije i korištenje snage Framework Class Library i sposobnosti ASP.NET-a za povezivanje podataka s različitim kontrolama kao što je GridView protiv DataSeta. Umjesto upotrebe jednostavnih DataSet objekata, možete koristiti Typed DataSet objekte i poboljšati iskustvo kodiranja implementacijom koda u prezentacijskom sloju kao iu sloju aplikacijske logike. Prednost ovog pristupa ujedno je i nedostatak pristupa. Male promjene podatkovnog modela ne moraju nužno dovesti do toga da mnoge metode moraju promijeniti svoje potpise. Što se tiče održavanja, ovo stvarno dobro funkcionira. Ako se sjećate da prezentacijski sloj nije nužno korisničko sučelje, može biti i web usluga. A ako izmijenite definiciju skupa podataka, možda zato što mijenjate naziv polja u bazi podataka, tada mijenjate ugovor na koji se web usluga pretplaćuje. Kao što možete zamisliti, to može dovesti do nekih značajnih problema. Ovaj scenarij dobro funkcionira ako je prezentacijski sloj samo korisničko sučelje, ali za sučelja prema vanjskim sustavima ili komponentama, htjet ćete sakriti unutarnji rad svoje aplikacije i transformirati podatke u nešto što nije izravni klon vašeg modela podataka i htjet ćete stvoriti objekte prijenosa podataka (DTO).
Tijek podataka korištenjem relacijskog preslikavanja objekata
Tijek podataka koji koristi ADO.NET pristup je vrlo usmjeren na podatke za upravljanje protokom podataka. Podaci i logika su diskretni. Drugi kraj spektra ima pristup koji je više orijentiran na objekte. Ovdje se stvaraju klase za grupiranje podataka i ponašanja. Cilj je definirati klase koje oponašaju podatke i ponašanje u poslovnoj domeni za koju je aplikacija stvorena. Rezultat se često naziva poslovnim objektom. Skup poslovnih objekata koji čine aplikaciju naziva se model domene. Neki programeri tvrde da je model bogate domene bolji za dizajniranje složenije logike. Teško je dokazati ili opovrgnuti takvu tvrdnju. Samo znaj da imaš izbor i da je na tebi da ga napraviš.
Slika 8-6 prikazuje tok podataka sličan slici 8-5, osim što ste sada dodali sloj relacijskog preslikavanja objekata i zamijenili DataSet objekte s različitim nositeljima podataka.
Sada napravite isto korak po korak kao i prije; zamislite da se netko spojio na vašu knjižaru i naručio tri knjige. Prezentacijski sloj upravlja stanjem košarice za kupnju. Kupac je spreman za narudžbu i dao je sve potrebne podatke. Odabire poslati narudžbu. Web stranica sve podatke pretvara u DTO, držeći podatke za jednu narudžbu i s tri retka narudžbe, stvarajući objekte prema potrebi. Web stranica ponovno prikazuje te podatke korisniku, kontrolira povezivanje podataka u odnosu na DTO pomoću ObjectDataSource u ASP.NET 2.0 i pita Jeste li sigurni? Korisnik potvrđuje izbor i DTO se podnosi logičkom sloju aplikacije. Logički sloj aplikacije pretvara DTO u poslovni objekt tipa Order sa svojstvom da sadrži tri objekta OrderLine. Metoda naloga. Validate() se poziva za provjeru valjanosti narudžbe i provjere imaju li sva obavezna polja vrijednost, te se vrši provjera da se utvrdi ima li korisnik više od R$ 1.000,00 u slipovima na čekanju. Da biste to učinili, narudžba će pozvati Order.Customer.GetOutstandingBills(). Ako je sve u redu, poziva se metoda Order.Save(). Zahtjev će proći kroz sloj relacijskog preslikavanja objekta, gdje se zahtjev i retci zahtjeva mapiraju u DataTable u DataSet-u, a DataSet se prosljeđuje sloju za pristup podacima, koji se povezuje s bazom podataka i generira izjave umetanja iz informacije u DataSet-u. Postoji, naravno, mnogo načina na koje se može dogoditi objektno-relacijsko preslikavanje, ali neće svi uključivati transformaciju u DataSet. Neki će izravno stvoriti naredbu za umetanje, ali će i dalje koristiti sloj pristupa podacima za izvršenje te naredbe.
Kao što vidite, događaju se neke transformacije. Korištenje DTO-a je neophodno jer poslovni objekt implementira ponašanje, a ponašanje je podložno promjenama. Kako biste umanjili utjecaj ovih promjena na prezentacijski sloj, trebate transformirati podatke iz poslovnog objekta u objekt za prijenos podataka. U Javi se objekt za prijenos podataka često naziva objekt vrijednosti.
Velika prednost rada s poslovnim objektima je ta što stvarno pomaže organizirati vaš kod. Ako se osvrnete na složenu logiku, obično je vrlo čitljiva jer postoji vrlo malo vodovodnog koda. Nedostatak je što je većina pohrana podataka još uvijek relacijska i mapiranje poslovnih objekata u relacijske podatke može postati prilično složeno.
usluge temeljene na shemi
Upravo ste vidjeli dvije suprotnosti kada je riječ o upravljanju protokom podataka. Moguće su mnoge varijacije. Uobičajena je varijanta u kojoj se skup podataka koristi kao osnovni nositelj podataka korisničkog sučelja za pohranjivanje podataka, ali se zasebne sheme (DTO) koriste za web usluge pozvane iz drugih sustava. Aplikacijski sloj transformira relacijske podatke u unaprijed definiranu shemu. Glavna prednost ovoga je da svaka aplikacija koja se poziva na uslugu ne ovisi o bilo kakvoj internoj implementaciji komponente. To omogućuje veću fleksibilnost u izradi verzija, kompatibilnost sučelja sa prethodnim verzijama i mogućnost promjene implementacije komponente bez promjene sučelja usluge.
Naravno, možete koristiti poslovne objekte u web aplikaciji i zaobići DTO transformaciju, ali to obično dobro funkcionira samo ako je logika aplikacije implementirana zajedno s web aplikacijom. Zapamtite da će vam za pozivanje Order.Save() trebati veza s bazom podataka. Je li to poželjno ovisi o vama i vjerojatno o vašem direktoru sigurnosti.