людинно-машинна взаємодія / HCI_Labs / HCI_lab2

Лабораторна робота №2

Тема: Аналіз предметної області проектування. Сценарії використання.

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

Теоретичні відомості

Мета аналізу предметної області

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

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

які вже були виявлені та реалізовані, і по-друге уникнути помилок та недоліків інших систем при реалізації власної.

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

Дослідження предметної області, відносно проектування інтерфейсу

взаємодії користувача з системою, можна розбити на два основних етапи:

дослідження сценаріїв використання системи (роботи користувача);

дослідження структури та функціонування інтерфейсу.

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

другий дозолить ознайомитись з деталями реалізації інтерфейсу та буде розглядатися в наступній лабораторній роботі.

Сценарії використання

Сценарій - це один із способів опису структури задачі. Це розповідь у розповідній формі яка описує діях, історію, чи епізод, що відбувається в даних тимчасових рамках і в даному контексті. Різні форми сценаріїв широко застосовуються при розробці програмного забезпечення.

Сценарії завдань і взаємодій зазвичай багаті характеристиками і володіють високою реалістичністю. Сценарії при розробці інтерфейсу описують взаємодію між користувачем (або моделлю користувача) і

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

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

Моделі use case

Концепція моделей use case вперше була застосована для розробки технічного завдання (ТЗ) Айваром Якобсоном в якості складової частини

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

орієнтованих» в елементах use case немає, тому їх можна застосовувати практично до всіх підходів проектування.

Елемент use case - це ситуація, варіант використання, тобто деякий випадок застосування системи. По суті use case це:

забезпечення функціональності;

суто зовнішня точка зору (принцип «чорного ящика»);

оповідальний опис;

опис взаємодії між користувачем та системою;

завершене і зрозуміле користувачу використання системи.

Кожен елемент use case описує в оповідальній формі добре налаоджений та чітко встановлений процес взаємодії, що має ясну мету та прозорі етапи з точки зору користувача. При об'єктно-орієнтованому підході елементи use case можуть описувати взаємодію з іншими системами і устаткуванням, а не тільки з живими користувачами. Тим не менше, коли метою розробка користувальницького інтерфейсу, можна абсолютно спокійно обмежитися розглядом тільки тих елементів use case, які відносяться до взаємодії людини і комп’ютера.

Сутнісні елементи use case

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

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

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

При використанні підходу, орієнтованого на зручність використання, в

сутнісних елементах use case, які представляють із себе структурований опис,

можна виділити три частини: виклад загальних прагнень користувача,

виражене в елементі use case, а також опис який складається з двох частин,

включає в себе модель користувальницьких устремлінь і модель організацією системи. Сутнісні елементи use case мають бути проімеоновані, причому ці імена повинні виражати наміри користувачів в умовах конкретного варіанту використання. У відповідності з угодою, запропонованою Якобсоном,

елемент use case зображується у вигляді еліпса з ім'ям елемента.

Опис варіантів використання

Функціональні вимоги до системи моделюються і документуються за допомогою варіантів використання (use case). Варіант використання (use case) – це зв'язний елемент функціональності, що надається системою при взаємодії з діючими особами. Дійова особа (actor) - роль, узагальнення елементів зовнішнього середовища системи, що ведуть себе по відношенню до системи однаковим чином.

В контексті процесу управління вимогами, варіанти використання трактуються наступним чином (згідно Коберну):

варіант використання фіксує угоду між учасниками проекту щодо поведінки системи;

варіант використання описує поведінку системи при різних умовах, коли система відповідає на запит одного з учасників, який називається основною дійовою особою;

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

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

загальному випадку, рекомендується дотримуватися таких правил:

назви варіантів використання повинні бути діловими (не технічними) термінами, що мають значення для замовника;

кожен варіант використання повинен являти собою завершену транзакцію між користувачем і системою, що представляє для першого деяку цінність;

добре написаний варіант використання легко читається і складається з пропозицій, написаних в єдиній граматичній формі.

На навчання читання варіанту використання не повинно йти більше декількох хвилин.

Формат опису варіанта використання

Нижче приведений формат опису варіанту використання деякої системи

розроблений Коберном:

1.Ім'я - мета у вигляді короткої активної дієслівної фрази.

2.Контекст використання – більш конкретний опис мети.

3.Область дії – опис середовища виконання процесу.

4.Рівень точності – відповідність очікуваного результату реальному в залежності від параметрів роботи.

5.Основна дійова особа – коротка характеристика основної дійової

особи.

6.Інші учасники та їх інтереси – перелік інших учасників і їх ролей у процесі.

7.Передумова – визначає, умову яка має бути гарантовано виконана перед тим, як система дозволить запуск варіанту використання.

8.Мінімальні гарантії – мінімальні результати роботи системи,

зокрема, коли мета основної діючої особи не може бути досягнута.

9.Гарантії успіху - або пост-умова - postcondition - встановлює, що інтереси учасників задовольняються при успішному завершенні варіанту використання в кінці основного сценарію.

10.Тригер – подія, яка запускає варіант використання.

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

взаємодію двох дійових осіб;

кроки підтвердження для захисту інтересу учасника;

внутрішні зміни для задоволення інтересу учасника.

12.Доповнення – запускаються при виникненні певної умови.

Включають послідовність кроків, які описують що відбувається, і

завершується досягненням мети або відмовою від неї.

13.Список змін у технології і даних – включає перелік змін внутрішнього стану системи.

14.Допоміжна інформація – інформація яка може доповнити чи пояснити деякі аспекти варіанту використання.

Практичне завдання

1.Дослідити сучасні рішення в предметній області (обрати три

інформаційні системи). Зробити короткий опис сфери та особливостей

використання кожної з обраних систем.

2.Виявити основні задачі які вирішуються системами та ключові сценарії їх розв’язання.

3.З обраних інформаційних систем у першому завдання вибрати одну (за власним бажанням) та скласти для неї три сценарії використання програмного продукту згідно до формату запропонованому Коберном. Один сценарій використання представити у двох видах – розширеному розповідному, та структурному у вигляді use case діаграм.

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

1.Яким чином проводиться моделювання задач?

2.Що таке сценарій використання?

3.Що таке елемент use case?

4.Що таке сутнісні елементи use case?

5.Чим відрізняються сценарії використання від моделі use case?

6.Яким чином можна описати варіанти використання?

7.Наведіть приклад опису варіанта використання по Коберн?

Зміст звіту

1.Титульний лист;

2.Короткі теоретичні відомості;

3.Результати дослідження сучасних рішень в предметній області згідно до індивідуального завдання п.1;

4.Сценарії використання обраного програмного продукту.

5.Висновки.

Рекомендована література

1. А.Коберн. Современные методы описания функциональных

тренований к системам – М.: «Лори».