24.1. Удосконалення процесу розроблення програмного забезпечення
Ідея формалізації процесу розроблення ПЗ розвивалася протягом десятиліть. У цьому навчальному посібнику спробуємо тільки стисло розглянути основні віхи історії.
24.1.1. Безпосередній процес розроблення пз
Ще на початку удосконалення обчислювальної техніки ніяких формальностей процесу розроблення ПЗ не було. Здебільшого програміст обговорював фізичний зміст технічного завдання з конкретним замовником чи потенційними користувачами і відразу ж брався писати код програми. Це було, втім, цілком прийнятно навіть для великих, як на той час, програм.
24.1.2. Каскадний процес розроблення пз
Коли програмісти стали більш кваліфікованими фахівцями, то вони почали ділити процес розроблення ПЗ на декілька етапів, що мали б виконуватися послідовно. Ця ідея насправді була запозичена з виробничих процесів. Етапи були такі: аналіз, планування, кодування і впровадження. Така послідовність часто називалася каскадною моделлю, оскільки процес завжди йшов у одному напрямку від аналізу до впровадження, як показано на рис. 24.1. Для реалізації кожного з етапів стали залучатися окремі групи програмістів, і кожна з них передавала результати своєї праці наступній.
Рис. 24.1. Каскадна модель розроблення ПЗ
Набутий досвід показав, що каскадна модель має множина недоліків. Адже малося на увазі, що кожний з етапів виконується без помилок або з мінімальною їх кількістю. Так, зазвичай, майже не буває в повсякденній роботі програмістів. Кожна етап привносила свої помилки, їх кількість від етапу до етапу наростала, як снігова лавина, роблячи всю програму однією великою помилкою.
До того ж у процесі розроблення ПЗ замовник міг змінити свої вимоги, а після закінчення етапу планування вже складно було знову повернутися до нього. Виявлялося у підсумку, що до моменту завершення написання програма вже просто застарівала.
24.1.3. Використання ооп
Як вже було сказано в розд. 11, саме по собі ООП створювалося для вирішення деяких проблем, що є притаманними процесу удосконалення методики розроблення великих програм. Зрозуміло, процес планування під час використання ООП різко спрощується, оскільки об'єкти програми відповідають об'єктам реального світу.
Але саме по собі ООП не вказує нам, що повинна робити програма; воно придатне тільки після того, як визначено мету і завдання проекту. Початковою, як і завжди, є етап "ініціалізації", коли потрібно з'ясувати вимоги замовника і чітко уявити собі потреби потенційних користувачів. Тільки після цього можна починати планування об'єктно-орієнтованої програми. Але як же нам зробити цей перший крок?
24.1.4. Сучасні підходи до розроблення пз
За останні роки з'явилося множина нових концепцій розроблення ПЗ. Вони визначають певну послідовність дій і способи взаємодії замовників, постановників завдань, розробників і програмістів. На сьогодні жодна мова моделювання не володіє тією універсальністю, яка є властивою UML. Багато експертів дотепер не можуть повірити, що один і той же підхід до розроблення ПЗ може бути застосований до створення проектів будь-яких видів. Навіть коли вже вибраний якийсь процес, то може з часом знадобитися, залежно від застосування програми, достатньо серйозно його змінити. Як приклад сучасної методики розроблення ПЗ розглянемо основні ознаки підходу, якому ми дамо назву уніфікований процес.
Уніфікований процес був розроблений тими ж фахівцями, які створили UML: Греді Бучем (Grady Booch), Айвором Джекобсоном (Ivar Jacobson) і Джеймсом Рембо (James Rumbaugh). Іноді цю концепцію називають раціональним уніфікованим процесом (Rational Unified Process, за назвою компанії, в якій його було розроблено) або уніфікованим процесом розроблення ПЗ.
Уніфікований процес розроблення ПЗ поділяється на чотири етапи: початок; удосконалення; побудова; передача.
На початковому етапі виявляються загальні можливості роботи майбутньої програми і здійсненність її функцій. Етап закінчується схваленням керівництвом проекту. На етапі удосконалення планується загальна архітектура системи. Саме тут визначаються вимоги користувачів. На етапи побудови здійснюється планування окремих деталей системи і пишеться власне код програми. На етапі впровадження система представляється кінцевим користувачам, тестується та впроваджується.
Всі чотири етапи можуть бути розбиті на ряд так званих ітерацій. Зокрема, етап побудови складається з декількох ітерацій. Кожна з них є підмножиною всієї системи і відповідає певним завданням, поставленим замовником1. На рис. 24.2 показано етапи уніфікованого процесу.
Рис. 24.2. Етапи уніфікованого процесу розроблення ПЗ
Кожна ітерація включає свою власну послідовність етапів аналізу, планування, реалізації і тестування. Ітерації можуть повторюватися кілька разів. Метою ітерації є створення працюючої частини системи.
На відміну від каскадного процесу розроблення ПЗ, уніфікований процес дає можливість повернутися на попередні етапи розроблення. Наприклад, зауваження, зроблені користувачами на етапі передачі, повинні бути враховані на попередніх етапах, що приводить до перегляду етапу побудови і, можливо, етапу удосконалення.
Необхідно зазначити, що розглядувана концепція уніфікованого процесу розроблення ПЗ може бути застосована до будь-яких типів програмної архітектури, а не тільки до проектів, у яких використовуються об'єктно-орієнтовані мови. Насправді, напевно, якраз слабкою стороною цього підходу є не дуже-то активне використання ООП.
Етап удосконалення зазвичай за основу бере технологію варіантів використання (use case). Це відправна точка детального розроблення системи. З цієї причини уніфікований процес розроблення ПЗ називають прецедентним. У наступному підрозділі ми розглянемо цю технологію, а потім застосуємо її до проекту, узятого нами як приклад.