1.3 Використання uml
UML (Unified Modeling Language) — уніфікована мова об'єктно-орієнтованого моделювання, використовується у об'єктно-орієнтованому програмуванні. Є невід'ємною частиною уніфікованого процесу розробки. UML може бути застосовано для розробки діаграм. Діаграма у UML – це графічне представлення набору елементів у виді зв'язаного графа з вершинами (сутностями) і ребрами (відносинами). Діаграми виконують певні функції. З їх допомогою можна зв'язати вимоги до програмного продукту один з одним. Різні види діаграм які підтримуються UML, і найбагатший набір можливостей представлення певних аспектів системи робить UML універсальним засобом опису як програмних, так і ділових систем.
Діаграми дають можливість представити систему у такому вигляді, щоб її можна було легко перевести в програмний код [15].
UML прекрасно зарекомендувала себе в багатьох успішних програмних проектах. Моделі розроблені в UML, дозволяють значно спростити процес кодування і направити зусилля програмістів безпосередньо на реалізацію системи. Діаграми підвищують супроводжуваність проекту і полегшують розробку документації.
1.4 Визначення моделі процесу розробки програмного забезпечення
В даний час є видимою тенденція у бік збільшення об'єму робіт, пов'язаних з розробкою програмного забезпечення.
В основі діяльності по створенню і використанню програмного забезпечення є поняття життєвого циклу. Цикл розробки програмного забезпечення – це структурований поділ, покладений в процесі розробки програмного продукту. Існують кілька моделей для цього процесу, кожна з яких описує свій підхід до елементів поділу, присутніх у процесі розробки програмного забезпечення. Під моделлю мається на увазі структура, яка визначає послідовність виконання і взаємозв'язку процесів, дій і завдань протягом життєвого циклу. З існуючих нині моделей найбільш поширеними є такі моделі: водоспадна та ітеративна[8].
1.4.1 Модель водопаду
Класичною моделлю процесу розробки програмного забезпечення є модель водопаду. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота на поточному.
Рисунок 1.1 – Модель водопаду процесу розробки ПЗ [8]
Аналіз вимог полягає у зборі вимог до програмного продукту. Результатом аналізу є специфікація у текстовому вигляді. На етапі проектування розроблюються діаграми, при необхідності використовують їх текстовий опис. Реалізація – це процес програмування. Результатом є програмний код з введенням коментарів. Інтеграція – процес об’єднання окремих програмних компонентів. Тестування – процес відладки програмного забезпечення.
Насправді перераховані фази не слідують послідовно один за одним, а частково перекриваються. На практиці будь-яку з фаз можна починати до того, як буде повністю завершена попередня.
Часто водоспадний процес може бути розширений додатковими фазами:
Рисунок 1.2 – Більш деталізована модель водопадного процесу розробки
-
Концептуальний аналіз полягає у визначенні загальних принципів додатка і виконуваний на самому початку процесу.
-
Об'єктно-орієнтований аналіз полягає у виділенні ключових класів і виконуваний після аналізу вимог і до фази проектування.
-
Фази компонентне та системне тестування. Тестування окремих частин програми та всього додатка, як єдиного цілого.
-
Супровід полягає в модифікації і внесенні виправлень в додаток.
Вживання процесу "водопаду" ефективне для систем, для яких на самому початку розробки можна досить точно і повно сформулювати всі вимоги, з тим щоб надати розробникам свободу реалізувати їх якнайкраще з технічної точки зору. У цю категорію потрапляють складні розрахункові системи, системи реального часу і інші подібні завдання. Проте, в процесі використання цього підходу виявилися ряд його недоліків, викликаних перш за все тим, що реальний процес створення програмних систем ніколи повністю не укладався в таку жорстку схему. В процесі створення програмного забезпечення постійно виникала потреба в поверненні до попередніх етапів і уточненні або передивляється раніше прийнятих рішень.