Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
KPZ.docx
Скачиваний:
1
Добавлен:
01.03.2025
Размер:
875.49 Кб
Скачать

Семестровий модуль 1. Моделювання предметної області та створення діаграм взаємодії

Змістовий модуль 1. Загальні положення. Методи та послідовність конструювання

Лекція 1. Загальні положення.

Література: 1 [27-30]; 2[43-59];3[315-353];8; 9; 13

Місце конструювання у процесі розробки ПЗ. Порівняння структурного і об’єктноорієнтованого підходів. Уніфікований процес проектування та інші технології.

Поняття життєвого циклу програмного забезпечення

Одним з основних понять інженерії ПЗ є поняття життєвого циклу програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ визначається періодом часу від ухвалення рішення про створення ПЗ до моменту повного вилучення програмного продукту з експлуатації.

  1. Основними моделями ЖЦ прийнято вважати [1, 2]:

  2. каскадну модель;

  3. еволюційну модель;

  4. модель формальної розробки систем;

  5. модель розробки ПЗ на основі раніше створених компонентів.

Під конструюванням ПЗ розуміється детальний виклад процесу створення програмного модуля, починаючи від інтерпретації вимог до створення програмного коду, його інтеграційного тестування й налагодження.

Порівняльна характеристика структурного й об’єктно-орієнтованого підходів Об’єктно-орієнтований підхід має такі переваги в порівнянні з структурним:

  1. Об'єктна модель більш природна, оскільки орієнтована на людське сприйняття миру.

  2. Об'єктна декомпозиція дозволяє створювати програмні системи меншого розміру за рахунок використання загальних механізмів. Підвищується рівень уніфікації розробки й можливість її повторного використовування.

  3. Об'єктна декомпозиція підтримує еволюційний шлях розвитку системи, що знижує складність розробки.

Об'єктна модель дозволяє повною мірою використовувати виразні можливості об'єктних і об’єктно-орієнтованих мов програмування.

Недоліками об’єктно-орієнтованого підходу є:

  1. Деяке зниження продуктивності ПЗ за рахунок великої кількості використовуваних методів, реалізації поліморфізму тощо.

  2. Ефект від впровадження об’єктно-орієнтованого підходу проявляється після виконання декількох схожих проектів і накопичення повторно використовуваних компонентів.

  3. Об’єктно-орієнтовані бази даних поки не можуть конкурувати з реляційними, якщо необхідно використовувати великі обсяги даних. У таких випадках потрібне відображення класів на реляційну модель.

У цей час використовуються два підходи, але об’єктно-орієнтований підхід одержує все більше широке поширення.

Уніфікований процес UP (Unified Process)

Уніфікований процес UP (Unified Process) [1, 4, 7] – це широко відомий процес розробки об’єктно-орієнтованих систем.

Його практична реалізація пов'язана з Rational Software, яка розробила й підтримує продукт Rational Unified Process (RUP).

RUP забезпечує строгий підхід до розподілу завдань і відповідальності усередині організації-розроблювача. Його призначення полягає в тім, щоб гарантувати створення точно в строк і в рамках установленого бюджету якісного ПЗ, яке відповідає потребам кінцевих користувачів.

Ітеративний життєвий цикл ґрунтується на постійному розширенні й доповненні системи в процесі декількох ітерацій з періодичним зворотним зв'язком і адаптацією модулів, що додаються, до існуючого ядра. Система постійно розростається крок за кроком, тому такий підхід іноді називають ітеративною й інкрементальною розробкою.

На кожній ітерації розробки розглядається невелика підмножина вимог, для задоволення яких швидко розробляється, реалізується й тестується невелика частина системи. На початкових ітераціях вимоги й модель проекту можуть бути дуже далекі від ідеалу. Однак досить стислі термінові рамки кожної ітерації, на якій виконується весь процес проектування й реалізації, забезпечують швидкий і своєчасний зворотний зв'язок і спілкування між користувачами, розроблювачами й фахівцями з тестування.

В результаті кожної ітерації утворюється працююча, але не повнофункціональна система. Таких ітерацій може бути 10-15. Результат ітерації не прототип, а скоріше остаточна версія деякої частини всієї системи. Ітерації можуть додавати нові функції або вдосконалювати вже існуючі рішення. Наприклад, можна присвятити ітерацію підвищенню продуктивності системи.

Методологія Microsoft Solutions Framework (MSF)

MSF [14] – це методологія ведення проектів і розробки рішень, що базується на принципах роботи над продуктами самої фірми Microsoft . MSF часто відносять до категорії «гнучких» технологій, через можливість адаптації до різних типів проектів і кількості розроблювачів.

Методологія Scrum

Методологія Scrum [15], що одержала популярність в 1995 році, дозволяє гнучко розробляти проекти невеликими командами (7 чоловік плюс/мінус 2) у ситуації вимог, що змінюються. При цьому процес розробки ітеративний і надає велику свободу команді.

Крім того, методологія дуже проста – легко вивчається й застосовується на практиці.

Екстремальне програмування ( eXtreme Programming- ХР)

Екстремальне програмування [13] – методологія розробки програмних систем, заснована на поступовому поліпшенні системи й розробці її дуже короткими ітераціями. По своїй суті XP – це одна з так званих "гнучких" методологій розробки ПЗ, що являє собою невеликий набір конкретних правил, які дозволяють максимально ефективно виконувати вимоги сучасного підходу до керування програмними проектами.

Контрольні запитання

  1. Що таке життєвий цикл ПЗ?

  2. З чого складається життєвий цикл ПЗ?

  3. Що таке модель життєвого циклу ПЗ?

  4. Які особливості, переваги й недоліки каскадної моделі ЖЦ?

  5. Які особливості, переваги й недоліки еволюційної моделі ЖЦ?

  6. Які особливості, переваги й недоліки моделі формальної розробки ПЗ?

  7. Які особливості, переваги й недоліки моделі розробки ПЗ на основі раніше створених компонентів?

  8. Які особливості спіральної моделі ЖЦ?

  9. Як вирішується проблема складності при створенні великих ПП?

  10. Які принципи покладені в основу структурного підходу до розробки ПП?

  11. Що розуміють під «об'єктом» при об’єктно-орієнтованому підході до створення ПЗ?

  12. Що розуміють під «класом» при об’єктно-орієнтованому підході до створення ПЗ?

  13. Які принципи покладені в основу об’єктно-орієнтованого підходу до створення ПЗ?

  14. У яких випадках об’єктно-орієнтований підхід до створення ПЗ має переваги порівняно зі структурним?

  15. У яких випадках структурний підхід до створення ПЗ має переваги порівняно з об’єктно-орієнтованим?

  16. Що відносять до основ конструювання?

  17. З яких елементів складається керування конструюванням?

  18. Які основні процеси конструювання визначені в RUP?

  19. Що мається на увазі під ітерацією в рамках уніфікованого процесу?

  20. Які переваги ітеративної розробки ПЗ?

  21. Які характерні риси методології MSF?

  22. Які характерні риси методології Scrum?

  23. Які характерні риси методології XP?

  24. У чому ідея розробки через тестування?

  25. Як визначається модуль, що підлягає розробці?

  26. Які вимоги слід реалізувати у програмному модулі?

  27. Як формується команда розробників програмного модуля?

  28. Які вимоги треба реалізувати під час тестування програмного модуля?

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]