Яка різниця між включенням та розширенням діаграми випадку використання?

Яка різниця між includeта extendу діаграмі випадку використання ?

Extend використовується тоді, коли випадок використання додає кроки до іншого випадку використання першого класу.

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

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

Наприклад, потік подій, який відбувається на початку кожного випадку використання банкоматів (коли користувач вводить свою карту банкоматів, вводить свій PIN-код і показує головне меню), був би хорошим кандидатом для включення.

Це може бути суперечливим, але "включає завжди, а подовження буває іноді" - це дуже поширене оману, яке майже зараз переймається як фактичне значення. Ось правильний підхід (на мій погляд, і перевіряється щодо Якобсона, Фоулера, Лармена та 10 інших посилань).

Стосунки - це залежності

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

включати

Базовий випадок використання залежить від включених випадків використання; без нього / базовий випадок використання є неповним, оскільки включені випадки використання представляють підряд послідовності взаємодії, яка може виникати завжди АБО іноді. . як основний сценарій і це не має значення).

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

розширити

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

Розширення випадків використання можна використовувати в декількох ситуаціях:

1. Базовий випадок використання являє собою функцію "must have" проекту, тоді як розширюваний випадок використання є необов'язковим (слід / міг / бажати) поведінкою. Саме тут термін необов’язковий - необов'язково, чи будувати / доставляти, а не необов'язково, чи він іноді працює як частина базової послідовності використання.
2. На фазі 1 ви можете доставити базовий випадок використання, який відповідає вимогам в цій точці, а фаза 2 додасть додаткову функціональність, описану випадком розширеного використання. Це може містити послідовності, які завжди або іноді виконуються після доставки фази 2 (знову всупереч поширеній помилковій думці).
3. Він може бути використаний для вилучення подальших випадків базового використання, особливо коли вони представляють "виняткову" складну поведінку з власними альтернативними потоками.

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

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

ПІДСУМОК

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

Я часто використовую це для згадування двох:

Мій випадок використання: я їду в місто.

включає -> керувати автомобілем

розширює -> заливаємо бензин

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

Випадки використання використовуються для документування поведінки, наприклад, відповіді на це питання.

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

Також зауважте, що дослідження відповіді не має особливого сенсу, якщо ви не намагаєтесь відповісти на питання.

Поведінка включається в іншу, якщо вона є частиною поведінки, що включає, наприклад, вхід для обміну стеками.

Щоб уточнити, ілюстрація справедлива лише в тому випадку, якщо ви хочете відповісти тут у переповненні стека :).

Це технічні визначення зі сторінок 671-672 UML 2.5 .

Я підкреслив те, що, на мою думку, є важливим моментом.

Подовжує

Extend - це відношення від розширюваного UseCase (розширення) до розширеного UseCase (розширеногоCase), яке визначає, як і коли поведінка, визначена в розширюваній UseCase, може бути вставлена ​​в поведінку, визначену в розширеній UseCase. Розширення відбувається в одній або декількох конкретних точках розширення, визначених у розширеному UseCase.

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

Розширений UseCase визначається незалежно від що проходить USECASE і має сенс незалежно від що проходить USECASE . З іншого боку, UseCase , що розширюється, як правило, визначає поведінку, яка не обов'язково може мати сенс сама по собі . Натомість UseCase, що розширюється, визначає набір модульних приростів поведінки, які збільшують виконання розширеного UseCase в конкретних умовах.

...

Включає

Include - це пряме відношення між двома UseCases, що вказує на те, що поведінка включеного UseCase (додавання) вставляється у поведінку включаючи UseCase (у тому числіCase ). Це також різновид NamedElement, щоб він міг мати ім'я в контексті власного UseCase (у тому числіCase). У тому числі UseCase може залежати від змін, що виникають при виконанні включеної UseCase. Включена UseCase повинна бути доступною, щоб поведінка включаючи UseCase була повністю описана.

Співвідношення Включити призначене для використання, коли є спільні частини поведінки двох або більше UseCases. Потім ця загальна частина витягується в окремий UseCase, щоб включати всі базові UseCases, що мають цю спільну частину . Оскільки основне використання відносин "Включити" призначене для повторного використання загальних частин, те, що залишається в базовому UseCase, як правило, не є повною, але залежить від того, щоб деталі, що входять до складу, були значимими. Це відображається в напрямку взаємозв'язку, вказуючи на те, що базове UseCase залежить від доповнення, а не навпаки.

...

Я думаю, що важливо зрозуміти намір включає і розширює:

"Взаємозв'язок включення призначений для повторного використання поведінки, змодельованої іншим випадком використання , тоді як відношення розширення призначене для додавання частин до існуючих випадків використання , а також для моделювання додаткових системних служб" (Overgaard і Palmkvist, Use Cases: Patterns and Blueprints. Addison -Веслі, 2004).

Це звучить для мене як:

Включити = повторне використання функціональних можливостей (тобто включена функціональність використовується або може бути використана в іншому місці системи). Отже, Include позначає залежність від іншого випадку використання.

Розширює = додає (не повторно використовуючи) функціональність, а також будь-яку додаткову функціональність. Таким чином, розширення можуть позначати одну з двох речей:
1. додавання нових функцій / можливостей до випадку використання (необов'язково чи ні)
2. будь-яких необов'язкових випадків використання (існуючих чи немає).

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

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

Щоб спростити,

для include

1. Коли виконується випадок базового використання, включений випадок використання виконується ВСЕ .
2. Базовий випадок використання потребував завершення включеного випадку використання для того, щоб його завершити.

типовий приклад: між логіном та підтвердженням пароля

(логін) --- << включати >> --- > (підтвердити пароль)

для успішного процесу входу також має бути успішним "перевірити пароль".

для extend

1. Коли виконується випадок базового використання, випадок розширеного використання виконується лише SOMETIMES
2. Випадок розширеного використання відбудеться лише тоді, коли будуть виконані певні критерії.

типовий приклад: між входом та повідомленням про помилку (лише трапляється іноді)

(логін) < --- << розширення >> --- (показати повідомлення про помилку)

"показати повідомлення про помилку" трапляється лише іноді, коли процес входу не вдався.

Я думаю, що тут пояснено msdn досить легко зрозуміти.

Включити [5]

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

Розширити [6]

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

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

ПРИКЛАДИ:

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

Користувач не може завантажити з сайту до завантаження матеріалу. Отже, я не можу завантажити, якщо нічого не завантажено.

Ви розумієте?

Йдеться про умовний наслідок. Я не можу цього зробити, якщо раніше цього не робив .

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

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

для випадків використання, що мають автентифікацію, найгірший сценарій, або необов'язкові, тоді можна продовжити.

приклад: для використання запиту на вступ, зустріч, бронювання квитка ВИ МОЖЕТЕ заповнити форму (реєстрацію або форму зворотнього зв’язку) .... сюди слід включити ..

Наприклад: для випадку використання підтвердження входу або входу в обліковий запис, ваша автентифікація є необхідною. Також потрібно думати про найгірші сценарії. Як повернути книгу з штрафом .. НІКОЛІ не отримуючи бронювання .. оплата рахунку ПІСЛЯ ДАТИ ДАТИ .. Це де продовжує грати ...

не зловживайте включенням та розширенням діаграм.

ЗБЕРІТЬ ПРОСТО СИЛЬНО !!!

Також остерігайтеся версії UML: давно вже використовувалося, що << використання >> і << включає >> були замінені << включити >>, а << розширення >> на „ розгорнути >> І узагальнити“ .
Для мене це часто оманливий момент: як приклад повідомлення та посилання Стефані - про стару версію:

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

Насправді, немає реальної альтернативи "оплаті за товар"! В даний час UML "оплата за доставку" - це розширення, а "оплата за допомогою paypal" / "оплата карткою" - це спеціалізація.

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

Наприклад, розгляньте випадок служби електронної пошти, тут "Логін" - це включений випадок використання, який потрібно запустити для надсилання електронної пошти (Base use case)

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

наприклад, розгляньте "Придбання ноутбука" як базовий випадок використання та "Додаткова гарантія" як розширений випадок використання, тут ви можете запустити базовий випадок "Покупка ноутбука", навіть не беручи додаткової гарантії.

Це чудовий ресурс із великим поясненням: що стосується випадку використання? Що таке розширення у випадку використання?

Розширений випадок використання зазвичай визначає необов'язкове поведінку. Це не залежить від розширеного випадку використання

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

Елементи діаграми

• Актори: Також їх називають Ролями. Ім'я та стереотип актора можна змінити на вкладці Властивості.

• Спадщина: Вдосконалення відносин між суб'єктами. Це відношення може носити ім’я та стереотип.

• Випадки використання: вони можуть мати точки розширення.

• Точки розширення: це визначає місце, де можна додати розширення.

• Асоціації: між ролями та випадками використання. Корисно давати асоціації, які говорять імена.

• Залежності: між випадками використання. Залежності часто мають стереотип, щоб краще визначити роль залежності. Щоб вибрати стереотип, виберіть залежність від діаграми або панелі навігації, а потім змініть стереотип на вкладці Властивості. Існує два особливі види залежності: <<extend>>і <<include>>, для яких Посейдон пропонує власні кнопки (див. Нижче).

• Розширена взаємозв'язок: односпрямована залежність між двома випадками використання. Розширений зв'язок між випадком B і випадком A означає, що поведінка B може бути включена до A.

• Включити взаємозв'язок: Одностороннє відношення між двома випадками використання. Такий взаємозв'язок між випадками використання A і B означає, що поведінка B завжди включена в A.

• Системна межа: системна межа фактично не реалізована як елемент моделі в Poseidon для UML. Ви можете просто намалювати прямокутник, надіслати його на другий план і використовувати його як системний кордон, помістивши всі відповідні випадки використання всередину прямокутника.

Обидва <include>і <extend>залежать від базового класу, але <extend>необов'язковий, тобто він є похідним від базового класу, але, з точки зору користувачів, він може використовуватися або не може використовуватися.

<include>включено в базовий клас, тобто його обов'язково використовувати <include>у випадку використання, інакше це вважатиметься неповним.

наприклад:

У машинобудуванні банкоматів (відповідно до точки зору користувачів):

1: Вилучення, депозит готівки та перевірка рахунку підпадає під дію, <extend>оскільки від користувача залежить, чи буде знято, чи депозит чи чек. Це необов’язкові речі, які робить користувач.

2: "Введіть PIN-код, розміщення картки, вилучення картки" - це те, що підпадає під дію, <include>оскільки користувач повинен і повинен розмістити карту та ввести дійсний штифт для перевірки.

Я не рекомендую використовувати це для пам’яті двох:

Мій випадок використання: я їду в місто.

включає -> керувати автомобілем

розширює -> заливаємо бензин

Я вважаю за краще, щоб ви використовували: Моє використання: я їду в місто.

продовжує -> водіння автомобіля

включає -> залити бензин

Мене вчать, що продовжувати відносини продовжує поведінку базового класу. Функціональні можливості базового класу повинні бути там. З іншого боку, відносини включають подібні до функцій, які можуть бути викликані. Травень жирним шрифтом.

Це можна побачити з використання Agilemodeling повторного використання в моделях із застосуванням

Тут роз'яснено різницю між обома. Але то , що не було пояснено то , що <<include>>і <<extend>>повинен не просто бути використані на всіх.

Якщо ви читаєте Bittner / Spence, то знаєте, що випадки використання стосуються синтезу, а не аналізу. Повторне використання випадків використання - це нісенітниця. Це чітко показує, що ви неправильно вирізали свій домен. Додана вартість сама по собі повинна бути унікальною. Єдине повторне використання доданої вартості, про яке я знаю, - це франшиза. Тож якщо ви займаєтесь гамбургерськими справами, приємно. Але скрізь ваше завдання як BA - це спробувати знайти USP. І це повинно бути представлене на корисних випадках.

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

Простіше кажучи: якщо ви можете без вагань відповісти своєму начальнику "Я зробив ...", то "..." - це ваш випадок використання, оскільки ви отримали гроші за це. (Це також дасть зрозуміти, що "логін" зовсім не є випадком використання.)

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

Подовжує використовується, коли ви розумієте, що ваш випадок використання занадто складний. Отже, ви витягуєте складні кроки у власні випадки використання "розширення".

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

(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Системний аналіз та методи проектування, McGraw-Hill / Irwin, 2007)

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

Наприклад, припустимо, що у вас є обліковий запис Amazon, і ви хочете перевірити замовлення, ну неможливо перевірити замовлення без попереднього входу у свій рахунок. Тож потік подій хотів би так ...

Розширити відносини використовуються , щоб додати додатковий крок до потоку прецеденту, який, як правило , необов'язковий крок ...

Уявіть, що ми все ще говоримо про ваш рахунок Amazon. Припустимо, базовим випадком є ​​« Порядок», а «розширення» - « Amazon Prime» . Користувач може просто замовити товар регулярно, або у користувача є можливість вибрати Amazon Prime, що гарантує, що його замовлення надійде швидше за більш високу вартість.

Однак зауважте, що користувачеві не потрібно вибирати Amazon Prime, це лише варіант, вони можуть вирішити ігнорувати цей випадок використання.

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

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

Для більшої ясності та правил щодо випадків використання читайте мою статтю тут:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics