Філософія підходу до впровадження
підхід до водоспаду
Водоспадний підхід до впровадження програми вимагає від дизайнера консультації з одним або кількома представниками організації кінцевого користувача та запису всіх специфікацій програми. Як правило, специфікації надходять у вигляді набору функціональних документів або варіантів використання, написаних таким чином, щоб кінцевий користувач міг легко прочитати та зрозуміти документи.
Кінцевий користувач підписує ці документи, а потім документи збирає команда технічних дизайнерів, яка розробляє програму, створюючи різні артефакти, такі як діаграми моделей класів, діаграми станів, діаграми діяльності та моделі даних. Мета цього етапу — написати все настільки детально, щоб у розробника не виникло проблем зі створенням необхідного коду. Відбувається офіційна передача дизайну групі розробників і групі тестування. Після доставки команда розробників починає кодувати, а команда тестування використовує технічний дизайн у поєднанні з варіантами використання для створення тестових випадків і тестових сценаріїв.
Після того, як команда розробників завершує кодування, код передається групі тестувальників. Команда випробувачів виконує розроблені випробування на основі вимог і детального проекту. Будь-які проблеми будуть вирішені командою розробників. Після завершення процесу тестування та виправлення додаток доставляється кінцевому користувачеві для приймального тестування. Кінцевий користувач виконує остаточну перевірку, щоб переконатися, що додаток відповідає початковим вимогам. У разі схвалення він затверджує готовий продукт, і проект вважається завершеним. Після того, як команда розробників завершує кодування, код передається групі тестувальників.
Команда випробувачів виконує розроблені випробування на основі вимог і детального проекту. Будь-які проблеми будуть вирішені командою розробників. Після завершення процесу тестування та виправлення додаток доставляється кінцевому користувачеві для приймального тестування. Кінцевий користувач виконує остаточну перевірку, щоб переконатися, що додаток відповідає початковим вимогам. У разі схвалення він затверджує готовий продукт, і проект вважається завершеним. Після того, як команда розробників завершує кодування, код передається групі тестувальників. Команда випробувачів виконує розроблені випробування на основі вимог і детального проекту.
Будь-які проблеми будуть вирішені командою розробників. Після завершення процесу тестування та виправлення додаток доставляється кінцевому користувачеві для приймального тестування. Кінцевий користувач виконує остаточну перевірку, щоб переконатися, що додаток відповідає початковим вимогам. У разі схвалення він затверджує готовий продукт, і проект вважається завершеним.
Кінцевий користувач виконує остаточну перевірку, щоб переконатися, що додаток відповідає початковим вимогам. У разі схвалення він затверджує готовий продукт, і проект вважається завершеним. Кінцевий користувач виконує остаточну перевірку, щоб переконатися, що додаток відповідає початковим вимогам. У разі схвалення він затверджує готовий продукт, і проект вважається завершеним.
При використанні каскадного підходу проект може мати більше чи менше фаз, але ключовою особливістю є дуже формальний початок і кінець кожної фази з дуже формальними результатами.
Перевага каскадного підходу полягає в тому, що відповідальність команди, відповідальної за кожну фазу, є більшою. Зрозуміло, що вони повинні доставити, коли вони повинні це доставити і кому вони повинні це доставити. Часто команді розробників не потрібно буде взаємодіяти з користувачем. Це може бути дуже корисним, якщо передати розробку в іншу країну.
Основним недоліком підходу водоспаду є те, що в середовищі, де все організовано дуже формально, гнучкість реагування на зміни зменшується. Навіть пересування потрібно організовувати. Здається, дуже мало компаній роблять це ефективно, що часто призводить до значного збільшення накладних витрат. Щоб управляти витратами на проект, деякі компанії навіть відкладають будь-які зміни вимог до початкової доставки програми, фактично надаючи програму, яка не відповідає потребам кінцевого користувача.
спритний розвиток
Багато тривалих проектів розробки програмного забезпечення виходили за рамки бюджету й не вчасно постачали продукт. Передумовою філософії гнучкої розробки програмного забезпечення є мінімізація ризику шляхом розробки програмного забезпечення в короткі терміни, які називаються ітераціями, які зазвичай тривають від одного до чотирьох тижнів. Кожна ітерація схожа на окремий мініатюрний програмний проект і включає всі завдання, необхідні для випуску приросту нової функціональності: планування, аналіз вимог, дизайн, кодування, тестування та документація. Хоча ітерація може не додати достатньо функціональних можливостей, щоб гарантувати випуск продукту, гнучкий програмний проект має на меті мати можливість випускати нове програмне забезпечення в кінці кожної ітерації. Наприкінці кожної ітерації команда переглядає пріоритети проекту.
Метою гнучкої розробки програмного забезпечення є досягнення задоволеності клієнтів шляхом швидкої та безперервної доставки корисного програмного забезпечення; завжди прагне створити те, що потрібно клієнту; вітати, а не протидіяти пізнім змінам вимог; регулярно адаптуватися до мінливих обставин; мати тісну та щоденну співпрацю між підприємцями та розробниками, у якій віч-на-віч є найкращою формою спілкування.
Головною перевагою гнучкої розробки програмного забезпечення є гнучкість у роботі зі змінами, завжди спрямована на забезпечення результатів відповідно до потреб бізнесу. Недоліком, звичайно, є збільшення складності управління обсягом, плануванням і бюджетуванням. Іншим поширеним ризиком є обмежена увага до (технічної) документації.
Поступовий розвиток
Поступова розробка програмного забезпечення — це суміш гнучкої та водоспадної розробки. Програма розробляється, реалізується та тестується поступово, щоб кожен крок міг бути доставлений кінцевому користувачеві. Проект не буде завершено, доки не буде завершено останній крок. Він спрямований на скорочення каскаду шляхом визначення проміжних приростів і використання деяких переваг гнучкої розробки. На основі відгуків, отриманих щодо попереднього збільшення, можна внести коригування під час доставки наступного збільшення. Наступний приріст може складатися з нового коду, а також модифікацій попереднього коду.
Перевагою є те, що формальності залишаються на місці, але управління змінами стає легшим. Вартість багаторазового тестування та розгортання програми буде більшою, ніж одноразове виконання.
Керування потоком програм
Вибір підходу до управління потоком програм є дуже архітектурним завданням. Мета полягає в тому, щоб створити план вашої програми, де, як тільки ви почнете додавати функціональні можливості та код, усе буде мати своє місце. Якщо ви коли-небудь переглядали або писали високоякісний код, ви розумієте цей принцип.
Код організатора
Першим кроком у розробці програмного потоку є організація коду шляхом встановлення набору правил, які допоможуть створити план або схему програми. Технічне обслуговування, налагодження та виправлення помилок стане легшим, оскільки код розташований у логічному місці. Після того, як ви зробите основу, ви можете вибрати підхід до реалізації логіки вашої програми.
Шаблони проектування повинні відігравати важливу роль у проектуванні керування потоком програм. Протягом багатьох років було написано багато коду та розроблено багато рішень для повторюваних проблем. Ці рішення викладені в шаблонах проектування. Застосування шаблону проектування до типової проблеми проектування програмного забезпечення допоможе вам створити рішення, які легко впізнати та можуть бути реалізовані вашими колегами. Унікальні проблеми все одно потребуватимуть унікальних рішень, але ви можете використовувати шаблони проектування, щоб керувати собою у їх вирішенні.
Створення проекту
шари
Першим кроком є розгляд логічних рівнів. Зауважте, що шари – це не те саме, що шари, їх часто плутають або навіть вважають однаковими.
шари проти шарів
Шари — це створення меж у вашому коді. Верхній рівень може мати посилання на код у шарах нижче, але шар ніколи не може мати посилання на код у шарі вище. Рівні стосуються фізичного розподілу рівнів на кількох комп’ютерах. Наприклад, у трирівневій програмі інтерфейс призначений для роботи на настільному комп’ютері, логіка програми розроблена для роботи на сервері програм, а база даних працює на сервері баз даних. шар може складатися з кількох шарів.
Рисунок 8-1: Базова трирівнева організація
Шари відносяться до рівнів абстракції. Шари, показані на малюнку 8-1, справедливі для більшості програм. Ці рівні також називаються трьома основними рівнями та можуть мати інші назви. Як правило, код на рівні презентації може викликати служби на рівні логіки програми, але рівень логіки програми не повинен викликати метод на рівні презентації. Рівень презентації ніколи не повинен безпосередньо викликати рівень доступу до даних, оскільки це обійде відповідальність, реалізовану рівнем логіки програми. Рівень доступу до даних ніколи не повинен викликати рівень логіки програми.
Шари — це лише абстракція, і, мабуть, найпростіший спосіб реалізувати шари — створити папки у вашому проекті та додати код до відповідної папки. Більш корисним підходом було б розмістити кожен шар в окремому проекті, таким чином створюючи окремі збірки. Перевага розміщення логіки програми в збірці бібліотеки полягає в тому, що це дозволить вам створювати модульні тести за допомогою Microsoft Visual Studio або NUnit для перевірки логіки. Це також забезпечує гнучкість у виборі місця розгортання кожного шару.
Фізичні рівні
У корпоративній програмі ви очікуєте мати кілька клієнтів для однієї логіки. Фактично, що робить програму корпоративною програмою, це те, що вона буде розгорнута на трьох рівнях: клієнт, сервер додатків і сервер бази даних. Програма Microsoft Office Access, створена відділом продажів вашої компанії, хоча й дуже важлива для відділу продажів, не є корпоративною програмою.
Зауважте, що логіка програми та рівні доступу до даних часто розгортаються разом на сервері програм. Частиною розробки проекту є вибір доступу до сервера додатків за допомогою віддалених служб .NET або Web. Що б ви не вибрали, ви додасте код для легкого доступу до віддалених служб на рівні презентації. Якщо ви використовуєте веб-служби для доступу до служб на сервері програм, Visual Studio .NET зробить цю роботу за вас і згенерує код проксі, автоматично забезпечуючи реалізацію шаблону віддаленого проксі.
Додавання візерунків до шарів
Три основні рівні забезпечують огляд високого рівня. Давайте додамо кілька структурних моделей, щоб створити надійну корпоративну архітектуру. Результат показано на малюнку 8-2.
Зосередьтеся на рівні логіки програми. На малюнку 8-2 показано, що доступ до логіки програми здійснюється за допомогою шаблону фасаду. Фасад — це об’єкт, який забезпечує спрощений інтерфейс для більшої частини коду, такої як бібліотека класів. Фасад може зменшити залежність зовнішнього коду від внутрішньої роботи бібліотеки, оскільки більшість коду використовує фасад, що забезпечує більшу гнучкість у розробці системи. Для цього фасад забезпечить грубозернистий інтерфейс для колекції дрібнозернистих об’єктів.
потік рішень
Контроль потоку програм, також відомий як потік рішень, стосується того, як ви проектуєте служби на логічному рівні програми або, як ви бачили в попередньому параграфі, як ви проектуєте методи у своєму фасаді.
Є два підходи до організації ваших послуг:
- орієнтовані на дію
- керований державою
Підхід, орієнтований на дії
Організовуючи служби на основі дій користувача, ви реалізуєте логіку додатків, пропонуючи служби, кожна з яких обробляє певний запит від рівня презентації. Це також відомо як шаблон сценарію транзакції. Цей підхід популярний, тому що він простий і виглядає дуже природно. Прикладами методів, які використовують цей підхід, є BookStoreService.AddNewOrder(Order order) і BookStoreService.CancelOrder(int orderId).
Логіка, необхідна для виконання дії, реалізована в методі дуже послідовно, що робить код дуже читабельним, але також важчим для повторного використання. Використання додаткових шаблонів проектування, таких як шаблон модуля таблиці, може допомогти збільшити можливість повторного використання.
Державний підхід
Також можна реалізувати потік рішень програми набагато більш орієнтованим на стан способом. Сервіси, які пропонує сервер додатків, мають більш загальний характер, наприклад BookStoreService.SaveOrder(Order order). Цей метод перевірить статус замовлення та вирішить, додати нове замовлення чи скасувати існуюче.
Проекти структури даних
Ви повинні зробити кілька варіантів під час розробки структур даних. Перший вибір – це механізм зберігання даних, другий – цільове використання даних, а третій – вимоги до версії. Є три способи поглянути на структуру даних:
- Сервіси пропонують дані; дані є відображенням реляційної бази даних.
- Дані мають бути зіставлені з об’єктами, а служби надають доступ до об’єктів.
- Дані, що пропонуються службами, мають базуватися на схемі.
Вибір одного з трьох як основи для вашої структури потоку даних слід зробити на ранній стадії процесу проектування. Багато компаній мають інструкції, які передбачають один із трьох варіантів для всіх проектів, але, де це можливо, вам слід повторно оцінити варіанти для кожного проекту, вибираючи оптимальний підхід для поточного проекту.
Вибір механізму зберігання даних
Під час розробки вашої програми вам, безсумнівно, доведеться розробити якесь сховище даних. Доступні такі сховища та форми зберігання даних:
- запис
- файл app.config
- файли xml
- звичайні текстові файли
- База даних
- чергування повідомлень
Кожен магазин має свої унікальні характеристики та може бути адаптований до конкретних вимог.
Проектування потоку даних
Потік даних за допомогою ADO.NET
Впровадивши сервіси, орієнтовані на дані, на рівні логіки програми, ви розробите свій потік даних за допомогою ADO.NET. Бібліотека класів .NET Framework надає розширений інтерфейс прикладного програмування (API) для роботи з даними в керованому коді. API, який називається ADO.NET, можна знайти в просторі імен System.Data. Повне розділення носіїв даних і сховищ даних є важливою конструктивною особливістю ADO.NET. Такі класи, як DataSet, DataTable і DataRow, призначені для зберігання даних, але не зберігають інформації про те, звідки вони надійшли. Вони вважаються агностиками джерел даних. Окремий набір класів, таких як SqlConnection, SqlDataAdapter і SqlCommand, піклується про підключення до джерела даних, отримання даних і заповнення DataSet, DataTable і DataRow. Ці класи розташовані в підпросторах імен, таких як System.Data.Sql, System.Data.OleDB, System.Data.Oracle тощо. Залежно від того, до якого джерела даних ви хочете підключитися, ви можете використовувати класи в потрібному просторі імен, і залежно від обсягу продукту, який ви використовуєте, ви побачите, що ці класи пропонують більшу чи меншу функціональність.
Оскільки DataSet не підключено до джерела даних, його можна досить успішно використовувати для керування потоком даних у програмі. На малюнку 8-5 показано потік даних під час цього.
Давайте поглянемо на цей проект і уявімо, що хтось увійшов у вашу книжкову крамницю та замовив три книги. Презентаційний рівень керував станом кошика для покупок. Замовник готовий зробити замовлення та надав усі необхідні дані. Він вирішує відправити замовлення. Веб-сторінка перетворює всі дані в DataSet, що містить дві DataTables, одну для порядку та одну для порядку; вставляє DataRow для замовлення; і вставляє три DataRows для рядків замовлення. Потім веб-сторінка знову відображає ці дані користувачеві, прив’язуючи елементи керування даними до DataSet і запитуючи Ви впевнені? Користувач підтверджує запит, і він передається на логічний рівень програми. Рівень логіки програми перевіряє DataSet, щоб побачити, чи всі необхідні поля мають значення, і виконує перевірку, щоб побачити, чи має користувач більше 1000 US$. 00 за неоплаченими рахунками. Якщо все йде добре, DataSet передається на рівень доступу до даних, який підключається до бази даних і генерує оператори вставки з інформації DataSet.
Використання DataSet таким чином є швидким і ефективним способом створення програми та використання потужності бібліотеки класів Framework і здатності ASP.NET прив’язувати дані до різних елементів керування, таких як GridView, проти DataSet. Замість використання простих об’єктів DataSet ви можете використовувати об’єкти Typed DataSet і покращити кодування, реалізувавши код на рівні презентації, а також на рівні логіки програми. Перевага цього підходу є одночасно і недоліком підходу. Невеликі зміни в моделі даних не обов’язково призведуть до того, що багатьом методам доведеться змінити свої підписи. Отже, з точки зору обслуговування, це працює дуже добре. Якщо ви пам’ятаєте, що рівень презентації не обов’язково є інтерфейсом користувача, він також може бути веб-службою. І якщо ви змінюєте визначення DataSet, можливо тому, що ви перейменовуєте поле в базі даних, тоді ви змінюєте контракт, на який підписується веб-служба. Як ви можете собі уявити, це може призвести до серйозних проблем. Цей сценарій добре працює, якщо презентаційний рівень є лише інтерфейсом користувача, але для інтерфейсів із зовнішніми системами чи компонентами вам потрібно буде приховати внутрішню роботу вашої програми та перетворити дані на щось інше, ніж прямий клон вашої моделі даних і ви захочете створити об’єкти передачі даних (DTO).
Потік даних з використанням реляційного відображення об’єктів
Потік даних за допомогою ADO.NET — це дуже орієнтований на дані підхід до керування потоком даних. Дані та логіка є дискретними. Інший кінець спектру використовує більш об’єктно-орієнтований підхід. Тут створюються класи для групування даних і поведінки. Мета полягає в тому, щоб визначити класи, які імітують дані та поведінку в бізнес-доміні, для якого було створено додаток. Результат часто називають бізнес-об'єктом. Сукупність бізнес-об’єктів, які складають додаток, називається моделлю домену. Деякі розробники стверджують, що розширена модель домену краща для розробки складнішої логіки. Важко довести або спростувати таке твердження. Просто знайте, що у вас є вибір, і тільки від вас залежить його зробити.
На малюнку 8-6 показано потік даних, подібний до малюнка 8-5, за винятком того, що ви додали рівень реляційного відображення об’єктів і замінили об’єкти DataSet іншими носіями даних.
Тепер крок за кроком виконайте те саме, що й раніше; Уявіть, що хтось підключився до вашої книжкової крамниці та замовив три книги. Презентаційний рівень керував станом кошика для покупок. Замовник готовий зробити замовлення та надав усі необхідні дані. Він вирішує відправити замовлення. Веб-сторінка перетворює всі дані в DTO, зберігаючи дані для одного замовлення та з трьома рядками замовлення, створюючи необхідні об’єкти. Веб-сторінка знову відображає ці дані користувачеві, прив’язка даних контролює DTO за допомогою ObjectDataSource в ASP.NET 2.0 і запитує Ви впевнені? Користувач підтверджує вибір, і DTO надсилається на логічний рівень програми. Рівень логіки програми перетворює DTO на бізнес-об’єкт типу Order із властивістю містити три об’єкти OrderLine. Метод замовлення. Validate() викликається для підтвердження замовлення та перевірки того, що всі обов’язкові поля мають значення, і виконується перевірка, щоб визначити, чи має користувач більше R$ 1000,00 у незавершених листах. Для цього замовлення викличе Order.Customer.GetOutstandingBills(). Якщо все в порядку, викликається метод Order.Save(). Запит проходитиме через рівень реляційного відображення об’єктів, де запит і рядки запиту зіставляються з DataTable у DataSet, а DataSet передається на рівень доступу до даних, який підключається до бази даних і генерує оператори вставки з інформацію в DataSet. Звичайно, існує багато способів, за допомогою яких може відбуватися об’єктно-реляційне відображення, але не всі вони включатимуть перетворення в DataSet. Деякі створюють оператор вставки безпосередньо, але все одно використовують рівень доступу до даних для виконання цього оператора.
Як бачите, відбуваються деякі перетворення. Використання DTO є необхідним, оскільки бізнес-об’єкт реалізує поведінку, а поведінка може змінюватися. Щоб мінімізувати вплив цих змін на рівень презентації, потрібно перетворити дані з бізнес-об’єкта на об’єкт передачі даних. У Java об’єкт передачі даних часто називають об’єктом значення.
Великою перевагою роботи з бізнес-об’єктами є те, що це дійсно допомагає впорядкувати ваш код. Якщо ви озирнетеся назад на складну логіку, вона зазвичай дуже зрозуміла, оскільки коду сантехніки дуже мало. Недоліком є те, що більшість сховищ даних все ще є реляційними, і відображення бізнес-об’єктів у реляційних даних може стати досить складним.
послуги на основі схем
Ви щойно побачили дві протилежності, коли йдеться про керування потоком даних. Можливо багато варіацій. Поширеним є варіант, у якому набір даних використовується як основний носій даних інтерфейсу користувача для зберігання даних, але окремі схеми (DTO) використовуються для веб-сервісів, викликаних з інших систем. Прикладний рівень перетворює реляційні дані в попередньо визначену схему. Основна перевага цього полягає в тому, що будь-яка програма, яка посилається на службу, не залежить від будь-якої внутрішньої реалізації компонента. Це забезпечує більшу гнучкість керування версіями, зворотну сумісність інтерфейсів і можливість змінювати реалізацію компонента без зміни інтерфейсу служби.
Звичайно, ви можете використовувати бізнес-об’єкти у веб-програмі й обійти перетворення DTO, але зазвичай це добре працює, лише якщо логіка програми реалізована разом із веб-програмою. Пам’ятайте, що для виклику Order.Save() вам знадобиться підключення до бази даних. Чи бажано це, вирішуєте ви та, ймовірно, ваш директор служби безпеки.