Имплементатион Аппроацх Пхилосопхиес
приступ водопаду
Водопадни приступ имплементацији апликације захтева од дизајнера да се консултује са једним или више представника организације крајњег корисника и запише све спецификације апликације. Типично, спецификације долазе у скупу функционалних докумената или случајева употребе, написаних на такав начин да крајњи корисник може лако да прочита и разуме документе.
Крајњи корисник потписује ове документе, а документе затим прикупља технички дизајнерски тим који дизајнира апликацију, стварајући различите артефакте као што су дијаграми модела класа, дијаграми стања, дијаграми активности и модели података. Циљ ове фазе је да се све напише тако детаљно да програмер неће имати проблема са креирањем потребног кода. Постоји формална примопредаја дизајна развојном тиму и тиму за тестирање. Након испоруке, развојни тим почиње са кодирањем, а тестни тим користи технички дизајн у комбинацији са случајевима коришћења за креирање тест случајева и сценарија тестирања.
Након што развојни тим заврши кодирање, код се предаје тестном тиму. Тест тим изводи тестове које је дизајнирао на основу захтева и детаљног дизајна. Све проблеме ће решити развојни тим. Када се заврши процес тестирања и поправљања, апликација се испоручује крајњем кориснику на тестирање прихватања. Крајњи корисник врши коначну проверу да види да ли је апликација у складу са почетним захтевима. Ако је одобрен, он одобрава готов производ и пројекат је завршен. Након што развојни тим заврши кодирање, код се предаје тестном тиму.
Тест тим изводи тестове које је дизајнирао на основу захтева и детаљног дизајна. Све проблеме ће решити развојни тим. Када се заврши процес тестирања и поправљања, апликација се испоручује крајњем кориснику на тестирање прихватања. Крајњи корисник врши коначну проверу да види да ли је апликација у складу са почетним захтевима. Ако је одобрен, он одобрава готов производ и пројекат је завршен. Након што развојни тим заврши кодирање, код се предаје тестном тиму. Тест тим изводи тестове које је дизајнирао на основу захтева и детаљног дизајна.
Све проблеме ће решити развојни тим. Када се заврши процес тестирања и поправљања, апликација се испоручује крајњем кориснику на тестирање прихватања. Крајњи корисник врши коначну проверу да види да ли је апликација у складу са почетним захтевима. Ако је одобрен, он одобрава готов производ и пројекат је завршен.
Крајњи корисник врши коначну проверу да види да ли је апликација у складу са почетним захтевима. Ако је одобрен, он одобрава готов производ и пројекат је завршен. Крајњи корисник врши коначну проверу да види да ли је апликација у складу са почетним захтевима. Ако је одобрен, он одобрава готов производ и пројекат је завршен.
Пројекат може имати више или мање фаза када се користи приступ водопада, али кључна карактеристика је врло формалан почетак и крај сваке фазе, са врло формалним резултатима.
Предност водопада приступа је што је одговорност тима одговорног за сваку фазу већа. Јасно је шта треба да испоруче, када то треба да испоруче и коме то треба да испоруче. Често развојни тим неће морати да комуницира са корисником. Ово може бити веома корисно када се развој препусти другој земљи.
Главни недостатак водопада приступа је то што се, у окружењу где је све организовано на веома формалан начин, смањује флексибилност да се одговори на промене. Чак и кретање треба организовати. Чини се да врло мало компанија ово ради ефикасно, што често доводи до значајног повећања режијских трошкова. Да би управљале трошковима пројекта, неке компаније чак одлажу све промене захтева до почетне испоруке апликације, ефективно испоручујући апликацију која не задовољава потребе крајњег корисника.
агилни развој
Многи дуготрајни пројекти развоја софтвера превазишли су буџет и нису испоручили производ на време. Премиса филозофије агилног развоја софтвера је да се ризик минимизира развојем софтвера у кратким временским оквирима, који се називају итерацијама, које обично трају од једне до четири недеље. Свака итерација је као сопствени минијатурни софтверски пројекат и укључује све задатке неопходне за ослобађање повећања нове функционалности: планирање, анализу захтева, дизајн, кодирање, тестирање и документацију. Иако итерација можда неће додати довољно функционалности да гарантује издавање производа, агилни софтверски пројекат има за циљ да буде у могућности да објави нови софтвер на крају сваке итерације. На крају сваке итерације, тим поново процењује приоритете пројекта.
Циљ агилног развоја софтвера је постизање задовољства корисника кроз брзу и континуирану испоруку корисног софтвера; увек има за циљ да изгради оно што је потребно купцу; поздрављају, а не да се противе касним променама захтева; редовно се прилагођавају променљивим околностима; да имају блиску и свакодневну сарадњу између предузетника и програмера, у којој је разговор лицем у лице најбољи облик комуникације.
Главна предност агилног развоја софтвера је флексибилност у суочавању са променама, увек са циљем да се испоручи у складу са пословним потребама. Лоша страна је, наравно, повећање сложености управљања обимом, планирањем и буџетирањем. Други уобичајени ризик је ограничена пажња на (техничку) документацију.
Инкрементални развој
Инкрементални развој софтвера је мешавина агилног и водопада развоја. Апликација је дизајнирана, имплементирана и тестирана постепено тако да сваки инкремент може бити испоручен крајњем кориснику. Пројекат није завршен док се не заврши последњи корак. Циљ му је да скрати каскаду дефинисањем средњих прираста и коришћењем неких од предности агилног развоја. На основу повратних информација добијених о претходном инкременту, подешавања се могу извршити приликом испоруке следећег инкремента. Следеће повећање може се састојати од новог кода као и од модификација претходно датог кода.
Предност је што формалности остају на месту, али управљање променама постаје лакше. Трошкови тестирања и постављања апликације више пута биће већи него да се то уради само једном.
Контрола тока програма
Избор приступа контроли тока програма је веома архитектонски задатак. Циљ је да направите нацрт ваше апликације где, када почнете да додајете функционалност и код, све изгледа да има своје место. Ако сте икада прегледали или написали висококвалитетан код, разумете овај принцип.
Код организатора
Први корак у дизајнирању тока програма је организовање кода успостављањем скупа правила која ће помоћи у креирању нацрта, или оквира, апликације. Одржавање, отклањање грешака и исправљање грешака биће лакши јер се код налази на логичној локацији. Када завршите темељ, можете одабрати приступ имплементацији логике ваше апликације.
Дизајнерски обрасци треба да играју важну улогу у дизајну контроле тока програма. Током година, написано је много кода и осмишљена су многа решења за проблеме који се понављају. Ова решења су постављена у шаблонима дизајна. Примена шаблона дизајна на уобичајени проблем дизајна софтвера ће вам помоћи да креирате решења која су лако препознатљива и која могу да имплементирају ваши вршњаци. Јединствени проблеми ће и даље захтевати јединствена решења, али можете користити обрасце дизајна који ће вас водити у њиховом решавању.
Креирање пројекта
слојева
Први корак је разматрање логичких слојева. Имајте на уму да слојеви нису исти као слојеви, често се бркају или се чак сматрају истим.
слојеви наспрам слојева
Слојеви се односе на стварање граница у вашем коду. Горњи слој може имати референце на код у слојевима испод, али слој никада не може имати референцу на код у слоју изнад. Нивои се односе на физичку дистрибуцију нивоа на више рачунара. На пример, у трослојној апликацији, кориснички интерфејс је дизајниран да ради на десктоп рачунару, логика апликације је дизајнирана да ради на серверу апликација, а база података ради на серверу базе података наменских података и кода у сваком слој се може састојати од неколико слојева.
Слика 8-1: Основна трослојна организација
Слојеви се односе на нивое апстракције. Слојеви приказани на слици 8-1 важе за већину апликација. Ови нивои се такође називају три главна слоја и могу имати различита друга имена. По правилу, код у слоју презентације може да позива услуге у логичком слоју апликације, али логички слој апликације не сме да позива метод у слоју презентације. Слој презентације никада не би требало директно да позива слој приступа подацима, јер би то заобишло одговорности које имплементира логички слој апликације. Слој приступа подацима никада не би требало да позива логички слој апликације.
Слојеви су само апстракција и вероватно је најлакши начин за имплементацију слојева да креирате фасцикле у вашем пројекту и додате код у одговарајућу фасциклу. Кориснији приступ би био да се сваки слој постави у посебан пројекат, стварајући тако одвојене склопове. Предност стављања логике ваше апликације у библиотечки склоп је у томе што ће вам омогућити да креирате јединичне тестове, користећи Мицрософт Висуал Студио или НУнит, за тестирање логике. Такође ствара флексибилност у избору где да се распореди сваки слој.
Пхисицал Лаиерс
У пословној апликацији, очекивали бисте да имате више клијената за исту логику. У ствари, оно што апликацију чини апликацијом предузећа је то што ће бити распоређена у три слоја: клијент, сервер апликација и сервер базе података. Апликација Мицрософт Оффице Аццесс коју је креирало одељење продаје ваше компаније, иако је веома важна за одељење продаје, није корпоративна апликација.
Имајте на уму да се логика апликације и слојеви приступа подацима често постављају заједно на сервер апликација. Део дизајнирања пројекта је одабир да ли ћете приступити серверу апликација користећи удаљене .НЕТ или Веб услуге. Шта год да одаберете, додаћете неки код за лак приступ удаљеним услугама у слоју презентације. Ако користите веб услуге за приступ услугама на серверу апликација, Висуал Студио .НЕТ ће обавити посао уместо вас и генерисати прокси код, аутоматски обезбеђујући имплементацију обрасца удаљеног проксија.
Додавање шаблона у слојеве
Три основна слоја пружају преглед на високом нивоу. Хајде да додамо неке структурне обрасце да бисмо створили робусну архитектуру предузећа. Резултат је приказан на слици 8-2.
Фокусирајте се на слој логике апликације. Слика 8-2 показује да се приступ логици апликације користи шаблоном фасаде. Фасада је објекат који пружа поједностављени интерфејс за већи део кода, као што је библиотека класа. Фасада може да смањи спољне зависности кода од унутрашњег функционисања библиотеке јер већина кода користи фасаду, омогућавајући тако већу флексибилност у развоју система. Да би се то урадило, фасада ће обезбедити грубо зрнасто сучеље колекцији ситнозрнатих објеката.
ток одлучивања
Контрола тока програма, такође позната као ток одлучивања, односи се на то како дизајнирате услуге у логичком слоју апликације или, као што сте видели у претходном параграфу, како дизајнирате методе у својој фасади.
Постоје два приступа организовању ваших услуга:
- оријентисан на акцију
- вођено државом
Приступ оријентисан на акцију
Организовањем услуга заснованих на радњама корисника, имплементирате логику апликације нудећи услуге, од којих свака обрађује одређени захтев из слоја презентације. Ово је такође познато као образац скрипте трансакције. Овај приступ је популаран јер је једноставан и изгледа веома природно. Примери метода које следе овај приступ су БоокСтореСервице.АддНевОрдер(Ордер ордер) и БоокСтореСервице.ЦанцелОрдер(инт ордерИд).
Логика потребна за извођење радње се имплементира веома секвенцијално унутар методе, чинећи код веома читљивим, али и тежим за поновну употребу. Коришћење додатних шаблона дизајна, као што је образац модула табеле, може помоћи у повећању поновне употребе.
Приступ вођен државом
Такође је могуће имплементирати ток одлучивања апликације на начин који је много више оријентисан на државу. Услуге које нуди сервер апликација су генеричке природе, на пример БоокСтореСервице.СавеОрдер(поруџбина). Овај метод ће испитати статус поруџбине и одлучити да ли да додате нову или поништите постојећу.
Пројекти структуре података
Морате направити неколико избора када дизајнирате своје структуре података. Први избор је механизам за складиштење података, други је намењена употреба података, а трећи су захтеви за верзију. Постоје три начина да погледате дизајн структуре података:
- Услуге нуде податке; подаци су одраз релационе базе података.
- Подаци морају бити мапирани на објекте, а услуге обезбеђују приступ објектима.
- Подаци које нуде услуге морају бити засновани на шеми.
Одабир једног од три као основе за вашу структуру тока података требало би да се уради у раној фази процеса пројектовања. Многе компаније имају смернице компаније које налажу једну од три опције за све пројекте, али где је могуће, требало би да поново процените опције за сваки пројекат, бирајући оптималан приступ за пројекат који је при руци.
Избор механизма за складиштење података
Када дизајнирате своју апликацију, несумњиво ћете морати да дизајнирате неку врсту складишта података. Доступна су следећа складишта и облици складиштења података:
- Запис
- апп.цонфиг фајл
- кмл датотеке
- обичне текстуалне датотеке
- База података
- ред порука
Свака продавница има своје јединствене карактеристике и може се прилагодити специфичним захтевима.
Дизајнирање тока података
Проток података помоћу АДО.НЕТ-а
Имплементацијом услуга усредсређених на податке у логички слој апликације, ви ћете дизајнирати свој ток података користећи АДО.НЕТ. Библиотека класа .НЕТ Фрамеворк пружа обиман интерфејс за програмирање апликација (АПИ) за манипулацију подацима у управљаном коду. Позиван као АДО.НЕТ, АПИ се може наћи у именском простору Систем.Дата. Потпуно раздвајање носача података и складишта података је важна карактеристика дизајна АДО.НЕТ-а. Класе попут ДатаСет, ДатаТабле и ДатаРов дизајниране су за складиштење података, али не задржавају знање о томе одакле су подаци дошли. Они се сматрају агностицима извора података. Засебан скуп класа, као што су СклЦоннецтион, СклДатаАдаптер и СклЦомманд, брине о повезивању са извором података, преузимању података и попуњавању ДатаСет-а, ДатаТабле-а и ДатаРов-а. Ове класе се налазе у подпросторима имена као што су Систем.Дата.Скл, Систем.Дата.ОлеДБ, Систем.Дата.Орацле и тако даље. У зависности од извора података на који желите да се повежете, можете користити класе у правом именском простору, а у зависности од обима производа који користите, видећете да ове класе нуде више или мање функционалности.
Пошто ДатаСет није повезан са извором података, може се прилично успешно користити за управљање протоком података у апликацији. Слика 8-5 приказује ток података када се ово ради.
Хајде да погледамо овај пројекат и замислимо да се неко пријавио у вашу књижару и наручио три књиге. Презентациони слој је управљао стањем колица за куповину. Купац је спреман да изврши поруџбину и дао је све потребне податке. Он бира да пошаље налог. Веб страница трансформише све податке у скуп података који садржи две табеле података, једну за наруџбу и једну за ред; умеће ДатаРов за налог; и убацује три реда података за редове налога. Веб страница затим поново приказује ове податке кориснику, повезујући контроле података са скупом података и питајући Да ли сте сигурни? Корисник потврђује захтев и подноси се логичком слоју апликације. Логички слој апликације проверава ДатаСет да види да ли сва обавезна поља имају вредност и врши проверу да види да ли корисник има више од 1000 УС1ТП4Т. 00 на неизмирене рачуне. Ако све прође како треба, ДатаСет се прослеђује слоју за приступ подацима, који се повезује са базом података и генерише изразе за уметање из података о скупу података.
Коришћење ДатаСета на овај начин је брз и ефикасан начин за прављење апликације и коришћење снаге библиотеке класа оквира и способности АСП.НЕТ-а да повеже податке са различитим контролама као што је ГридВиев са скупом података. Уместо коришћења једноставних објеката ДатаСет-а, можете користити Типед ДатаСет објекте и побољшати искуство кодирања имплементацијом кода у слоју презентације као иу слоју логике апликације. Предност овог приступа је и мана приступа. Мале промене модела података не доводе нужно до тога да многе методе морају да мењају своје потписе. Дакле, у погледу одржавања, ово функционише заиста добро. Ако се сећате да слој презентације није нужно кориснички интерфејс, он може бити и веб услуга. А ако измените дефиницију скупа података, можда зато што преименујете поље у бази података, онда мењате уговор на који је веб услуга претплаћена. Као што можете замислити, ово може довести до неких значајних проблема. Овај сценарио добро функционише ако је слој за презентацију само кориснички интерфејс, али за интерфејсе за спољне системе или компоненте, желећете да сакријете унутрашње функционисање ваше апликације и трансформишете податке у нешто друго осим директног клона вашег модела података и желећете да креирате објекте за пренос података (ДТО).
Ток података коришћењем објектног релационог мапирања
Ток података коришћењем АДО.НЕТ-а је приступ управљању протоком података веома фокусиран на податке. Подаци и логика су дискретни. Други крај спектра је приступ који је више објектно оријентисан. Овде се креирају класе за груписање података и понашања. Циљ је да се дефинишу класе које опонашају податке и понашање пронађене у пословном домену за који је апликација креирана. Резултат се често назива пословним објектом. Колекција пословних објеката који чине апликацију назива се модел домена. Неки програмери тврде да је модел богатог домена бољи за дизајнирање сложеније логике. Такву изјаву је тешко доказати или оповргнути. Само знајте да имате избор и на вама је да га направите.
Слика 8-6 приказује ток података сличан оном на слици 8-5, осим што сте сада додали слој релационог мапирања објеката и заменили објекте ДатаСет различитим носиоцима података.
Сада урадите исти корак по корак као и раније; замислите да се неко повезао са вашом књижаром и наручио три књиге. Презентациони слој је управљао стањем колица за куповину. Купац је спреман да изврши поруџбину и дао је све потребне податке. Он бира да пошаље налог. Веб страница претвара све податке у ДТО, држећи податке за једну наруџбу и са три линије поруџбине, креирајући објекте по потреби. Веб страница поново приказује ове податке кориснику, везивање података контролише ДТО користећи ОбјецтДатаСоурце у АСП.НЕТ 2.0 и пита Да ли сте сигурни? Корисник потврђује избор и ДТО се доставља логичком слоју апликације. Логички слој апликације трансформише ДТО у пословни објекат типа Ордер са својством да садржи три ОрдерЛине објекта. Метод налога. Валидате() се позива да потврди поруџбину и провери да ли сва обавезна поља имају вредност, а врши се провера да би се идентификовало да ли корисник има више од Р1ТП4Т 1.000,00 у листићима на чекању. Да би то урадио, налог ће позвати Ордер.Цустомер.ГетОутстандингБиллс(). Ако је све у реду, позива се метода Ордер.Саве(). Захтев ће проћи кроз слој релационог мапирања објеката, где се захтев и редови захтева мапирају у ДатаТабле у ДатаСет-у, а ДатаСет се прослеђује слоју за приступ подацима, који се повезује са базом података и генерише изјаве за уметање из информације у скупу података. Наравно, постоји много начина на које може доћи до објектно-релационог мапирања, али неће сви укључити трансформацију у скуп података. Неки ће директно креирати наредбу за уметање, али ће и даље користити слој приступа подацима за извршење те изјаве.
Као што видите, дешавају се неке трансформације. Употреба ДТО-ова је неопходна јер пословни објекат имплементира понашање и понашање је подложно промени. Да бисте смањили утицај ових промена на слој презентације, потребно је да трансформишете податке из пословног објекта у објекат за пренос података. У Јави, објекат преноса података се често назива објектом вредности.
Велика предност рада са пословним објектима је у томе што заиста помаже у организовању вашег кода. Ако се осврнете на део сложене логике, обично је врло читљив јер има врло мало кода за водовод. Лоша страна је у томе што је већина складишта података још увек релациони и мапирање пословних објеката у релационе податке може постати прилично сложено.
услуге засноване на шеми
Управо сте видели две супротности када је у питању управљање протоком података. Могуће су многе варијације. Уобичајена је варијанта у којој се скуп података користи као основни носилац података корисничког интерфејса за складиштење података, али се засебне шеме (ДТО) користе за веб услуге које се позивају из других система. Апликациони слој трансформише релационе податке у унапред дефинисану шему. Главна предност овога је да било која апликација која упућује на услугу не зависи од било које врсте интерне имплементације компоненте. Ово омогућава већу флексибилност у верзионисању, компатибилност интерфејса уназад и могућност промене имплементације компоненте без промене интерфејса услуге.
Наравно, можете користити пословне објекте у веб апликацији и заобићи ДТО трансформацију, али то обично добро функционише само ако се логика апликације имплементира заједно са веб апликацијом. Запамтите да ће вам за позивање Ордер.Саве() бити потребна веза са базом података. Да ли је то пожељно зависи од вас и вероватно вашег директора безбедности.