USE CASE-діаграма. Приклади використання

До програмної та системної інженерії USE CASE-діаграма являє собою перелік дій чи кроків заходи, які зазвичай визначають взаємодію між роллю (певною мовою уніфікованого моделювання як «актор») і системою для досягнення мети. "Актор" може бути людської або іншої зовнішньої системою.

Визначення

USE CASE-діаграм мови UML — це важливий і цінний метод аналізу вимог, який широко використовується в сучасній розробці програмного забезпечення з часу офіційного запровадження Іваром Джекобсоном в 1992 році. Розробка з використанням програм залежить від багатьох моделей процесів і структур, таких як ICONIX, Unified Process (UP), IBM Rational Unified Process (RUP) і Oracle Unified Method (OUM).

Історія

У 1986 році Івар Якобсон спочатку сформулював текстові, структурні та візуальні методи моделювання для визначення варіантів використання. У 1992 році його співавтор книги «Об'єктно-орієнтована розробка програмного забезпечення — підхід, заснований на USE CASE», допоміг популяризувати техніку збору функціональних вимог, особливо в розробці. Інші експерти також внесли великий внесок, зокрема Алістер Кокберн, Ларрі Костянтин, Дін Леффингвелл, Курт Біттнер і Гуннар Овергаард. У 2011 році Джейкобсон опублікував оновлену інформацію про свою роботу під назвою Use Case 2.0 з наміром включити багато зі своїх практичних прикладів застосування прецедентів з моменту створення концепції.

Характер взаємодії елементів

Діаграма визначає взаємодію між зовнішніми учасниками і розглянутою системою для досягнення мети. Актор може бути людиною, компанією або організацією, комп'ютерною програмою, системної апаратурою або програмним забезпеченням. Учасник може грати як активну, так і пасивну роль: наприклад, споживач є одночасно покупцем (не взаємодіючим з системою) і користувачем ("актором", активно взаємодіє з придбаним продуктом). У свою чергу, користувач є звичайним оператором ("актором", що використовують систему за прямим призначенням) і функціональним бенефіціаром (зацікавленою стороною, що користується системою).

USE CASE-діаграми: склад, види зв'язків

USE CASE — це термін, присвячений програмного та системного проектування, який описує, як користувач використовує систему для досягнення певної мети. Цей процес діє як метод моделювання програмного забезпечення, визначає функції, які повинні бути реалізовані, і вирішення будь-яких помилок, які можуть виникнути. Існує три основних елементи процесу: "Актори" — це тип користувачів, які взаємодіють з системою. Система — функціональні вимоги, які визначають передбачуване поводження елементів. Цілі — USE CASE зазвичай ініціюються користувачем для виконання цілей, що описують дії і варіанти, беруть участь у їх досягненні. Характеристики методики: Організація функціональних вимог. Моделювання цілей взаємодії користувачів системи. Запис сценаріїв з тригерних подій в кінцеві цілі. Опис основного ходу дій і виключного потоку подій. Дозвіл доступу до функцій іншої події. Кроки при розробці діаграм: Визначте користувачів системи. Для кожної категорії створіть профіль користувача. Це включає в себе всі ролі, що мають відношення до системи. Визначте важливі цілі, пов'язані з кожною роллю для підтримки системи. Цінова пропозиція системи визначає значну роль. Створіть приклади використання для кожної мети, пов'язаної з шаблоном, і підтримуйте однаковий рівень абстракції в усьому прецеденті. Кроки використання більш високого рівня розглядаються як цілі більш низького рівня.

Термінологія

USE CASE-діаграма в Rational Rose — це діаграма динамічної поведінки в UML, яка моделює функціональність системи з використанням учасників, прецедентів та інших найважливіших об'єктів. Випадки використання — це набір дій, служб і функцій, які повинна виконувати система. У цьому контексті система — це те, що розробляється або експлуатується, наприклад веб-сайт. «Актори» (умовний термін) — це люди або організації, які працюють під певними ролями всередині системи.

Для чого застосовуються USE CASE-діаграми?

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

Що таке діаграма UML?

USE CASE-діаграма UML — це спосіб візуалізації програмного забезпечення з використанням набору діаграм. Основоположники технології — Греді Буч, Джеймс Румбо, Івар Якобсон і компанія Rational Software Corporation. Їх роботи лягли в основу об'єктно-орієнтованого дизайну, потім специфікації були розширені, щоб охопити більш широкий спектр проектів розробки програмного забезпечення. Сьогодні UML приймається групою управління об'єктами (OMG) в якості стандарту для розробки програмного забезпечення для моделювання.
Щоб відповісти на питання про те, що таке діаграма використання UML, необхідно спочатку зрозуміти її будівельні блоки. Загальні компоненти включають: користувачів, які взаємодіють з системою; певну послідовність дій і взаємодії між учасниками та сценарієм системи; кінцевий результат — успішна діаграма повинна описувати дії і варіанти, що використовуються для досягнення мети. У професійному співтоваристві програмістів для пояснення структури часто застосовують діаграми USE CASE «курочку Рябу» — візуальне зображення сюжету популярної казки у вигляді схеми.

Що таке UML?

UML означає Unified Modeling Language. UML 2.0 допоміг розширити вихідну специфікацію, щоб охопити більш широку частину зусиль з розробки програмного забезпечення, включаючи гнучкі методи. Також були реалізовані наступні розробки: покращена інтеграція між структурними моделями, такими як діаграми класів і моделі поведінки (діаграми активності); додана можливість визначати ієрархію і розкладати програмну систему на компоненти і подкомпоненти; в вихідному UML вказані дев'ять діаграм UML 2.0 збільшує це число до 13; чотири нових діаграми називаються: діаграма зв'язку, складова структурна діаграма, діаграма огляду взаємодії і тимчасова діаграма. Даний випуск також перейменував діаграми станів на державні машинні діаграми, або діаграми станів. Ключем до створення UML-діаграми є об'єднання форм, що представляють об'єкт або клас, з іншими фігурами для ілюстрації відносин потоку інформації і даних.

Типи діаграм

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

Ці діаграми організовані у дві групи: структурні та діаграми поведінки (або взаємодії).

Структурні, в свою чергу, поділяються на такі види діаграм: Класів є основою майже кожної об'єктно-орієнтованого методу, включаючи UML. Вони описують статичну структуру системи. Пакетів — підмножина діаграм класів. Розробники іноді розглядають як окремий метод. Пакетні діаграми організують елементи системи пов'язані групи, щоб мінімізувати залежності між пакетами. Об'єкта — описують статичну структуру системи в певний час. Вони можуть використовуватися для перевірки діаграм класів для точності.
Композитні структурні діаграми показують внутрішню частину класу. Моделюють функціональність системи з використанням учасників і прецедентів. Компонентів — описують організацію фізичних програмних компонентів, включаючи вихідний код, виконуваний файл (двійковий код). Діаграми розгортання відображають фізичні ресурси в системі, включаючи вузли, компоненти та сполуки. Поведінкові мають у своєму складі діаграми:
Діяльності — ілюструють динамічний характер системи шляхом моделювання потоку контролю від активності до активності. Дія являє собою операцію над деяким класом в системі, яка призводить до зміни стану системи. Як правило, діаграми активності використовуються для моделювання робочого процесу або бізнес-процесів і внутрішньої роботи. Послідовності описують взаємодії між класами в термінах обміну повідомленнями з плином часу. Стану — описують динамічну поведінку системи у відповідь на зовнішні подразники. Діаграми станів особливо корисні при моделюванні реактивних об'єктів, стану яких ініціюються певними подіями. Зв'язку — моделюють взаємодію між об'єктами в послідовності. Вони описують як статичну структуру, так і динамічну поведінку системи. У багатьох відносинах являють собою спрощену версію діаграми спільної роботи, введеної в UML 2.0. Огляду взаємодії — являють собою комбінацію діаграм активності та послідовності. Вони моделюють послідовність дій і дають змогу деконструювати більш складні взаємодії в керовані входження. Тимчасові — являють собою тип поведінкової або інтерактивної UML-діаграми, яка фокусується на процесах, які відбуваються протягом певного періоду часу. Є особливим прикладом діаграми послідовності.

Символи і позначення

Існує багато різних типів UML-діаграм, і кожен з них має свій набір символів. Класові діаграми є однією з найбільш поширених діаграм UML, а символи діаграм класів — одним з важливих атрибутів. Наприклад, є символи для активних класів і інтерфейсів. Символ класу можна фрагментувати, щоб показати операції, атрибути та обов'язки класу.
Лінії також є важливими символами для позначення відносин між компонентами. Узагальнення та спадкування позначаються порожніми стрілками. Залежно позначені пунктирною лінією зі стрілкою. Використання дозволяє вказати властивості цієї залежності. Множинність зазвичай відображається з номером на одному кінці стрілки і * з іншого. Діаграми пакетів мають символи, що визначають пакет, схожий на папку. Діаграми дій включають окремі символи для початкового і кінцевого стану. Потік управління зазвичай показаний стрілкою, а потік об'єкта — пунктирною стрілкою. Діаграми випадків використання мають символи для учасників і прецедентів.

Чому ми використовуємо UML?

Комплексне корпоративне додаток з великим штатом співробітників вимагає міцної основи планування і чіткої комунікації між членами команди по мірі просування проекту. Візуалізація взаємодії користувача, процесів і структури системи, яку ви намагаєтеся створити, допоможе заощадити час і переконатися, що всі учасники команди активно беруть участь у процесі. Послідовні діаграми описують взаємодії між класами в термінах обміну повідомленнями з плином часу. Вони також називаються діаграмами подій і є хорошим способом візуалізації та перевірки різних сценаріїв виконання. Дані об'єкти можуть допомогти передбачити, як система буде себе вести, і виявити обов'язки, що клас повинен виконувати в процесі моделювання нової системи. Приклад USE CASE-діаграма — графічне зображення взаємодій між елементами системи. Це методологія, яка використовується в системному аналізі для виявлення, уточнення і організації системних вимог. У цьому контексті термін «система» відноситься до того, що розробляється або експлуатується, наприклад веб-сайту з продажу та обслуговування товарів поштою. USE CASE-діаграма в UML (Unified Modeling Language) — стандартна нотація для моделювання об'єктів і систем реального світу.

Розшифровка понять

Цілі системи можуть включати в себе планування загальних вимог, перевірку апаратного проектування, тестування і налагодження розроблюваного програмного продукту, створення довідки з оперативної допомоги або виконання завдання, орієнтованої на споживача. Наприклад, використання діаграми варіантів USE CASE diagram в середовищі продажів включає в себе упорядкування товарів, оновлення каталогу, обробку платежів і відносини з клієнтами. Діаграма використання виглядає як блок-схема. Інтуїтивні символи являють собою елементи системи. Сценарії діаграм прецедентів USE CASE-банкомату містять чотири компоненти: Межа, яка визначає систему інтересу до навколишнього світу. "Актори", зазвичай люди, пов'язані з системою, що визначаються відповідно з їх ролями. Варіанти використання, які є конкретними ролями, які грають "актори" всередині і навколо системи. Взаємовідносини між суб'єктами. На уніфікованому мовою моделювання діаграма може підсумувати відомості про користувачів вашої системи (також відомих як суб'єкти) та їх взаємодії з системою. Щоб побудувати один об'єкт, ви будете використовувати набір спеціалізованих символів і коннекторів. Наприклад, USE CASE-діаграма інтернет-магазину може допомогти вашій команді обговорити і уявити: сценарії, в яких ваша система або програма взаємодіє з людьми, організаціями або зовнішніми системами; цілі і методи їх досягнення; об'єм системи.

Практичне застосування

USE CASE-діаграма не має великого значення при відсутності чіткого розуміння процесу — вона не буде моделювати порядок виконання кроків, якщо не закладено чіткий алгоритм. Експерти рекомендують використовувати дані діаграми для доповнення текстового варіанту. У діаграмі на високому рівні демонструється взаємозв'язок між варіантами використання, суб'єктами і системами. З цієї причини часто використовуються USE CASE uml-діаграми для політичної партії при моделюванні структури. Діаграма ідеальна в таких ситуаціях: представлення цілей системно-користувальницьких взаємодій; визначення та організація функціональних вимог до системи; виявлення контексту і вимог системи; моделювання основного потоку подій в прецеденті. Завдяки оптимальної візуалізації при моделюванні програмного забезпечення пральних машин USE CASE-діаграми застосовуються дуже широко. Для моделювання системи найбільш важливим аспектом є захоплення динамічної поведінки, яке означає поведінку системи при її запуску і подальшої роботи. В UML існує п'ять діаграм, доступних для моделювання динамічного характеру, і приклад USE CASE-діаграми найбільш наочний.

Призначення

Мета діаграми — захопити динамічний аспект системи. Однак це визначення є надто загальним для опису цілі. Так як інші чотири діаграми (активність, послідовність, спільне використання та Statechart) також мають однакову мету. USE CASE-діаграми використовуються для збору вимог до системи, включаючи внутрішні і зовнішні впливи (як правило, це вимоги до дизайну). Отже, коли аналізується система для збору її функціональних можливостей, розробляються приклади використання та ідентифікуються учасники. Коли початкова задача завершена, діаграми випадкових ситуацій моделюються для подання зовнішнього вигляду. Цілями при створенні USE CASE-діаграм можна назвати наступне: збір вимог; отримання зовнішнього вигляду системи; вплив зовнішніх і внутрішніх факторів; візуалізація взаємодії між вимогами та суб'єктами.

Процес створення

Діаграми використання використовуються для аналізу вимог високого рівня системи. Коли аналізуються вимоги до системи, функціональність фіксується у випадках використання. Можна сказати, що варіанти використання - це не що інше, як системні функції, написані організованим чином. Діаграми використовуються для врахування функціональних вимог системи. Після визначення вищевказаних пунктів ми повинні використовувати такі рекомендації для побудови діаграми ефективного використання: Ім'я прецеденту дуже важливо — виберіть його таким чином, щоб воно могло ідентифікувати виконувані функції. Дайте відповідне ім'я для акторів. Покажіть на графіку відносини і залежності. Не намагайтеся включити всі типи відносин, оскільки основна мета діаграми полягає у визначенні вимог. При необхідності використовуйте пояснення, щоб прояснити деякі важливі моменти.

Сфери застосування

В UML є п'ять діаграм для моделювання динамічного представлення системи. Кожна модель має певну мету використання. Насправді ці конкретні цілі застосовуються в різних напрямках працюючої системи. Щоб зрозуміти динаміку, потрібно використовувати різні типи діаграм. USE CASE-діаграми, склад, види зв'язків — найкращий приклад. Її конкретна мета - збирати системні вимоги учасників. Діаграми використовуються на дуже високому рівні дизайну, де дані уточнюються багаторазово до отримання повної та практичною картини. Добре структурований прецедент також описує попередня умова, стан повідомлення і виключення. Ці додаткові елементи використовуються для створення прикладів при проведенні тестування. В інженерії діаграми для створення тестових запитів, а у випадках зворотного проектування використовуються для підготовки інформації про вимоги з існуючого програми. USE CASE-діаграми можуть використовуватися для аналізу вимог і високорівневого дизайну, зіставлення контексту системи та зворотного інжинірингу.