Класифікація прототипів

Розглянемо наступні класифікації прототипів за К. Вігерсом [2]:

• горизонтальні і вертикальні;

• одноразові і еволюційні;

• паперові і електронні, розкадровування [5].

Горизонтальний або поведінковий прототип (horizontal prototype, behavioral prototype) моделює інтерфейс користувача додатку, не торкаючись логіки обробки і бази даних.

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

Горизонтальні прототипи слід використати для досягнення мети прояснення неясних, або багатоальтернативних вимог.

Вертикальний або структурний прототип (vertical prototype, structural prototype) не обмежується інтерфейсом користувача. Він реалізує вертикальний «зріз» системи, порушуючи усі рівні її реалізації. При створенні такого роду прототипів рекомендується використати ті мови і середовища реалізації, що і при виготовленні цільової системи (що є зовсім не обов'язковим для горизонтальних прототипів).

Основні цілі застосування такого роду прототипів - аналіз застосовності, перевірка архітектурних концепцій.

Одноразовий або дослідницький прототип (throwaway prototype, exploratory prototype) створюється, коли необхідно швидко отримати макети тих або інших аспектів та компонентів системи.

Цілям створення дослідницьких прототипів відповідає технологія RAD (rapid application development) – швидка розробка застосувань.

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

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

К. Вігерс приводить наступну схему переходу від одноразового прототипу до детально опрацьованого UI:

Рис.9.1. Перехід від одноразового прототипу до UI

На рис.9.1 присутнє нове поняття: «картка діалогу», говорять також «схема діалогу». Перш, ніж створювати горизонтальний прототип, необхідно визначитися - які основні екрани будуть присутніми, які вікна відкриватимуться, які правила переходу між ними будуть підтримуватись. Інформація такого роду добре лягає на модель діаграми станів, див. тему№8 «Моделювання вимог», де різним екранам (вікнам) зіставляються стани, а активним елементам управління, що викликають закриття одних інтерфейсних елементів і відкриття інших, – переходи.

Еволюційний прототип (evolutionary prototype) створюється, як перше наближення системи, покликане стати згодом самою системою.

Код еволюційного прототипу повинен послідовно, протягом однієї або більше ітерацій, перетворитися на код цільового застосування. Тому цей вид прототипів вимагає усього того, від чого слід відмовитися при створенні одноразових прототипів: прискіпливої розробки, застосування технологічних методів і прийомів, тестування результатів тощо.

У таблиці 9.1.наводиться співвідношення між розглянутими вище 4 видами прототипів [2].

Таблиця 9.1.

	Одноразові	Еволюційні
Горизонтальні	Прояснення і уточнення прикладів використання і функціональних вимог Виявлення пропущених вимог Дослідження можливих варіантів інтерфейсу користувача	Реалізація базових варіантів використання Реалізація додаткових варіантів використання по пріоритетах Реалізація і доопрацювання web-сайтів Адаптація системи до вимог бізнесу, що швидко міняються
Вертикальні	Демонстрація технічної здійсненності	Реалізація і нарощування ключової клієнт-серверної функціональності і рівнів комунікації Реалізація і оптимізація основних алгоритмів Тестування і налаштування продуктивності

Паперовий прототип (paper prototype) – гарна альтернатива розглянутим вище різновидам електронних прототипів у випадку, коли розробник обмежений у ресурсах. Нариси інтерфейсів на папері, звичайно, не замінять інтерфейс, створений у середовищі розробки. Проте, при усіх недоліках, у таких прототипів є дві істотні переваги:

1. Замовник не стане акцентувати увагу на колірному рішенні, формі кнопок, тощо, відволікаючись від аналізу функціональності.

2. Замовник ніколи не скаже, дивлячись на паперовий інтерфейс: «Та ви, як я бачу, вже створили систему на 85%! Давайте завершимо її за тиждень».