Основи uml - діаграми використання (use-case)
Незалежно від методології розробки, яку ви застосовуєте, першим етапом розробки буде формулювання вимог до продукту (Граддя Буч описує Rational Unified Process [1], а Розенберг - ICONIX [2]). Набір вимог до продукту є технічне завдання. при цьому вимоги діляться на функціональні (то, що система дозволяє зробити, бажана функціональність) і нефункціональні (вимоги до обладнання, операційній системі і т.п.). У мові UML для формалізації функціональних вимог застосовуються діаграми використання.
Діаграму варіантів використання є сенс будувати під час вивчення технічного завдання. вона складається з графічної діаграми, яка описує дійові особи і прецеденти. а також специфікації, що представляє собою текстовий опис конкретних послідовностей дій (потоку подій). які виконує користувач при роботі з системою. Специфікація потім стане основою для тестування і документації. а на наступних етапах проектування вона доповнюється і оформляється у вигляді діаграми (в рамках ICONIX використовується діаграма послідовності, але в UML для цього є також діаграми діяльності). Крім того, use-case діаграма досить проста, щоб її міг зрозуміти замовник, отже ви можете використовувати її для узгодження ТЗ (адже діаграма описує функціональні вимоги до системи).
На діаграмі використання зображуються:
На мій погляд, найбільш правильний порядок побудови діаграми наступний:
- виділити групи дійових осіб (які працюють з системою по-різному, часто через різні прав доступу);
- ідентифікувати якомога більше варіантів використання (процесів, які можуть виконувати користувачі). При цьому не слід ділити процеси занадто дрібно, потрібно вибирати лише ті, які дадуть користувачеві значущий результат. Наприклад, касир може «продати товар» (це буде прецедентом), проте «введення штрих-коду товару для отримання ціни» самостійним прецедентом не є;
- доповнити прецеденти словесним описом (сценарієм):
- для кожного прецеденту створити розділи: «головна послідовність» і «альтернативні послідовності»;
- при складанні сценарію потрібно наполегливо ставити замовнику питання «що відбувається?», «що далі?», «що ще може відбуватися?» і записувати відповіді на них.
Розглянемо розробку діаграм варіантів використання на прикладі - нехай замовник дав нам наступне технічне завдання:
Мета - розвиток у дітей математичних навичок.
Платформа: Linux, Windows, Android.
функціональність:
При першому запуску система повинна дозволяти ввести пароль вчителя. Завдання являють собою математичні задачі на додавання, віднімання, множення і ділення. У блоці завдань можуть бути завдання різних типів (вказується кількість). Крім введення типу виконуваної в прикладі операції необхідно вказувати допустимі діапазони чисел (або навіть окремі числа, тому що при вивченні таблиці множення часто спочатку вчать множення на 2, потім на 5, а тільки потім все інше). Крім того, для операції віднімання необхідно мати можливість встановити від'ємник менше зменшуваного (тому що в іншому випадку результат буде негативним, а негативні числа в школі проходять набагато пізніше).
Очевидно, незважаючи на те, що замовник дуже докладно описав деякі деталі, ми не можемо не тільки приступити до реалізації завдання, але навіть приблизно оцінити вартість і терміни виконання. З такого завдання не зрозуміло, наприклад, що повинні містити звіти. Однак, ми відразу можемо виділити дві групи користувачів і кілька видів їх діяльності.
Приклад діаграми використання
Суцільні лінії на діаграмі є відносини асоціації, що відображають можливість використання актором прецеденту. Після того, як визначено набір варіантів використання, можна приступати до складання сценаріїв. Сценарії повинні описуватися з точки зору користувача, при цьому важливо описувати взаємодію користувача з елементами інтерфейсу. Так наприклад сценарій прецеденту реєстрації учня міг би виглядати наступним чином:
Назва прецеденту: реєстрація учня
Дійова особа: учитель
Мета: додати учня в систему, отримавши його пароль
- учитель вибирає в головному меню пункт «додати учня«;
- система показує вчителю вікно додавання учня, що містить поля для введення логіна і пароль, н я, а також кнопки «далі» і «назад»;
- учитель вводить бажаний логін і пароль учня, натискає кнопку «далі»;
- система додає учня;
- вчителю відкривається головне меню і на протязі 5 секунд виводиться повідомлення про те, що учень був доданий успішно.
Альтернативна послідовність (повернення в головне меню без додавання учня):
- учитель вибирає в головному меню пункт «додати учня«;
- система показує вчителю вікно додавання учня, що містить поля для введення логіна і пароль, н я, а також кнопки «далі» і «назад»;
- учитель натискає кнопку «назад»;
- вчителю відкривається головне меню (при цьому дані, введені в форми вікна додавання учня не зберігаються).
Альтернативна послідовність (додавання учня, вже наявного в системі):
- учитель вибирає в головному меню пункт «додати учня«;
- система показує вчителю вікно додавання учня, що містить поля для введення логіна і пароль, н я, а також кнопки «далі» і «назад»;
- учитель вводить бажаний логін і пароль учня, натискає кнопку «далі»;
- вчителю протягом 5 секунд відображається повідомлення про те, що запитуваний логін зайнятий.
Аналогічним чином повинні бути прописані всі прецеденти, зображені на діаграмі. Складати сценарії потрібно досить наполегливо щоб описати всі можливі варіанти дій користувача в системі. Замовник може робити це з великим задоволенням, а програміст за рахунок цього раніше дізнається можливі побажання замовника (так з наведеного сценарію він міг би з'ясувати, що програма повинна відображати спливаючі повідомлення).
Незважаючи на простоту наведеного сценарію, в його послідовності можна знайти дублювання, якщо воно має місце в ваших сценаріях - ви можете виділити деякі фрагменти опису в окремі прецеденти (які можуть бути як самостійними, так і бути лише частиною інших варіантів використання). При цьому між прецедентами з'явиться або відношення розширення (extend), або включення (include). які відображаються на діаграмах (в UML також існує відношення узагальнення, а в OML - виклику і передування).
Ставлення включення на діаграмі використання
Ставлення розширення на діаграмі використання
Найтиповішими помилками при побудові цього виду діаграм є:
- неправильне використання відносин розширення і включення, в тому числі спроби використовувати діаграми для функціональної декомпозиції системи. Виникає через нерозуміння відмінностей між цими двома видами відносин і того, що use-case діаграма повинна виражати лише вимоги до системи, а не деталі її реалізації;
- розробка діаграми з точки зору програміста, а не користувача. У сценаріях повинні використовуватися назви елементів управління (видимі користувачеві), але небажано зображати деталі реалізації (такі як менеджер подій), які не зрозумілі замовнику;
- Мало опрацювання сценаріїв:
- відсутність або недостатня кількість альтернативних послідовностей, в яких повинен бути врахований, в тому числі, введення некоректних даних в систему;
- опис дій користувача без вказівки конкретних елементів інтерфейсу системи і відсутність описів реакції системи в сценаріях.
Важливо, що процес ICONIX є ітеративним, тому якщо ви допустите неточність на етапі розробки діаграм використання - їх можна буде знайти і виправити на наступних етапах (зокрема, пропущені об'єкти можуть бути виділені при роботі над діаграмами робастности, а сценарії детально опрацьовані при побудові діаграм послідовності).
Якщо слідувати всім наведеним правилам складання діаграм варіантів використання, з їх допомогою можна досить детально пропрацювати технічне завдання щоб оцінити терміни і вартість його виконання, описати конкретні сценарії взаємодії з системою, які ляжуть в основу тестів і документації. і узгодити все це з замовником.
У статті наведені основні можливості use-case діаграм. на мою думку їх повинно бути досить для розробки переважної більшості систем, при необхідності більшу кількість інформації і прикладів можна почерпнути в наступній літературі: