Моделі уніфікованого процесу розроблення ПЗ
Модель варіантів використання (use-case model) є концептуальною моделлю системи, що описує повну функціональність системи. Для побудови моделі варіантів використання в команді розробників виділяються співробітники, які виконують відповідні функції та створюють певні артефакти (рис.31). На рис.32 наведено схему робочого процесу розроблення моделі ВВ.
Співробітник – позначення ролі, що доручена одній або кільком особам, визначає потрібні для цієї дії якості та здібності. Артефакт (artifact) – частина інформації, що створюється, змінюється або використовується співробітником під час роботи системи, визначає область відповідальності та дає змогу керувати своїми версіями.
Рисунок 30 – Cпівробітникі, які будують модель варіантів використання
Рисунок 31 – Робочий процес побудови моделі ВВ
Модель аналізу (analysis model) будується на базі моделі ВВ для більш точного розуміння вимог, створення їх простого опису та для виявлення структури системи, в тому числі архітектури. На рис.32, 33 показані учасники процесу аналізу, створювані артефакти та схема робочого процесу розроблення моделі
Рисунок 32 – Співробітники, які будують модель аналізу
У табл.3 подано порівняння моделі аналізу із моделлю ВВ, з якого видно, що модель аналізу використовується розробниками, тоді як модель ВВ повинна бути зрозумілою і замовникові, і розробникам.
Рисунок 33 – Робочий процес побудови моделі аналізу
Таблиця 3 – Зіставлення моделі аналізу та моделі варіантів використання
| Характеристика | Модель ВВ | Модель аналізу |
| Використовує мову | замовника | розробника |
| Містить вигляд системи | зовнішній | внутрішній |
| Модель структурована за | Варіантами використання | класами та пакетами |
| Використовується | для домовлення між замовником та розробниками | розробниками для розуміння системи |
| Містить надлишковість, несумісні вимоги | так | ні |
| Визначає | функції системи та ВВ для подальшого аналізу | як функції реалізуються у реалізаціях ВВ |
Модель проектування (design model) є об’єктною моделлю, сконцентрованою на вимогах, функціональних та нефункціональних, які разом із обмеженнями середовища розроблення реалізують систему.
Зіставлення моделей проектування та аналізу (табл.4) показує, що модель проектування є формалізованим описом проекту системи, сконцентрованим на її реалізації.
Модель проектування має такі властивості:
- має ієрархічну структуру;
- реалізації ВВ є стереотипами кооперації;
- модель є кресленням реалізації.
Модель проектування розробляється разом із моделлю розгортання, оскільки проект системи неможливо створити без визначення фізичного розподілу системи за розрахунковими вузлами, що містить модель розгортання (deployment model). Також ця модель перевіряє, чи можуть ВВ бути реалізовані у вигляді компонентів, які виконуються у цих вузлах.
Таблиця 4 – Зіставлення моделей проектування та аналізу
| Характеристика | Модель аналізу | Модель проектування |
| Тип моделі | концептуальна | фізична |
| Залежність | від проекту | від реалізації |
| Рівень формалізації | низький | високий |
| Кількість стереотипів класів | Три – сутність (entity), керування (control), межа (boundary) | будь-яка |
| Розмір | невеликий | значний |
| Детальність | ескіз проекту системи | опис проекту системи з увагою до послідовності |
| Підтримка у ЖЦ | може не підтримуватись | підтримується весь ЖЦ |
| Визначає | структуру | систему, зберігаючи структуру моделі аналізу |
Розробники моделей проектування та розгортання, створювані ними артефакти наведені на рис.34.
Рисунок 34 – Співробітники та артефакти моделі проектування
Модель проектування розробляється відповідно до заданого порядку (рис.35):
- Ідентифікуються класи.
- Виділяються відповідальності.
- Проектуються класи та реалізації ВВ.
- Класи проектування збирають у підсистеми
- Визначають інтерфейси між підсистемами.
Рисунок 35 – Робочий процес побудови моделі проектування
Модель реалізації (implementation model) дає опис реалізації моделі проектування у вигляді компонентів програмного продукту. Елементи моделі та її розробники наведені на рис. 36.
Рисунок 36 – Співробітники та артефакти моделі реалізації
В уніфікованому процесі створення ПЗ передбачається покрокове розроблення. Результатом кожного кроку є білд (build) – виконувана версія системи.
Після визначення складових компонентів моделі створюється опис інтерфейсів їх взаємозв’язку та розробляється план складання, що дає опис послідовності ітерацій. Для кожного білду план містить опис:
- функцій, які потрібно реалізувати у білді (це перелік ВВ та/або сценаріїв або їх частин);
- частини моделі реалізації, що стосуються білду (перелік підсистем та компонентів, потрібних для реалізації функціональності).
У результаті виконання робочого процесу будується модель реалізації системи (рис.38).
Рисунок 37 – Робочий процес побудови моделі реалізації
Модель тестування (test model) описує, як виконувані компоненти моделі реалізації тестуються на цілісність та проходять системні тести. У розробленні моделі тестування задіяні чотири співробітники (рис. 38,39,40) – інженер з тестування (розробник тестів), інженер з компонентів, тестувальник цілісності та системний тестувальник.
Рисунок 38 – Артефакти, розроблювані інженером з тестування
Рисунок 39 – Артефакти моделі тестування, розроблювані інженером з компонентів, тестувальником цілісності та системним тестувальником
Модель тестування розробляється (рис. 39) з урахуванням вимоги, що кожен білд є об’єктом тестування і керується системою контролю версій системи. У моделі тестування розробляються тестові приклади – шляхи тестування системи, що містить предмет тестування, вхідні дані, результат та умови тестування, – та тестові процедури – методики запуску одного/кількох тестових прикладів або їх частин. Обов’язково складається план тестування, що містить опис стратегії тестування, виділених ресурсів та графіка робіт.
Рисунок 40 – Робочий процес побудови моделі тестування
Методологія RUP реалізована у програмному продукті Ration Software Architect компанії IBM. Як CASE-система, Ration Software Architect має велику кількість інструментів, корисних для підтримки зв’язку перших етапів проектування з етапом реалізації програм (кодування), а також з етапом оцінки. Зокрема перевіряється, що моделювання на різних етапах погоджено, що модельні угоди, визначення класів, інших елементів моделей та їх взаємозв’язку несуперечливі. Рівень автоматичного аналізу високий настільки, що дозволяє будувати за моделями так звані реалізації за замовчуванням. Це заготовки програмного коду, що включають у себе описи класів та їх методів у тому вигляді, що можна зробити з моделей. Програміст доповнює заготовки фрагментами, деталізує конкретну реалізацію. У Ration Software Architect та інших UML CASE- системах підтримується побудова реалізацій за замовчуванням за моделями загального, а не спеціального призначення. Реалізація за замовчуванням є лише одним із прийомів підтримки зв’язків між етапами життєвого циклу розроблення програмного забезпечення. Саме ідея комплексної підтримки зв’язаності робочих продуктів різних етапів, а не окремі прийоми, які з’являлися і раніше, – головне для даної CASE- системи. Програмне втілення цієї ідеї, нехай навіть з істотними недоробками, необхідно віднести до явних переваг даного інструментарію.