В чем разница между включением и расширением диаграммы использования?

В чем разница между include и extend в схеме case case?

Ответ 1

Расширение используется, когда вариант использования добавляет шаги в другой первоклассный вариант использования.

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

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

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

Ответ 2

Это может быть спорным, но "включенные всегда и постоянно расширяются" - это очень распространенное заблуждение, которое почти сейчас считается де-факто. Правильный подход (на мой взгляд, и проверка против Якобсона, Фаулера, Лармена и 10 других ссылок).

Отношения - это зависимости

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

включить

Базовый вариант использования зависит от включенного варианта использования; без него/их базовый вариант использования является неполным, так как включенные варианты использования представляют собой подпоследовательности взаимодействия, которые могут происходить всегда ИЛИ иногда. (Это противоречит популярному заблуждению об этом, то, что предлагает ваш случай использования, всегда происходит в основном сценарии, а иногда происходит в альтернативных потоках, просто зависит от того, что вы выбираете в качестве основного сценария, случаи использования можно легко перестроить, чтобы представлять другой поток как основной сценарий, и это не имеет значения).

В наилучшей практике односторонней зависимости базовый прецедент знает о (и ссылается) на включенный прецедент, но включенный прецедент не должен знать о базовом варианте использования. Вот почему включенные варианты использования могут быть: а) базовыми вариантами использования в их собственном праве и b) разделены несколькими базовыми вариантами использования.

расширяющие

Расширяющийся вариант использования зависит от базового варианта использования; это буквально расширяет поведение, описанное базовым вариантом использования. Базовый прецедент должен быть полностью функциональным прецедентом по своему усмотрению ( "включает в себя, конечно, без дополнительных возможностей использования" ).

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

Базовый пример использования представляет собой "должен иметь" функциональность проекта, в то время как расширяемый пример использования представляет собой необязательное (должно/может/нужно) поведение. В этом случае термин "необязательный" является релевантным - необязательно ли строить/доставлять, а не необязательно, иногда ли он выполняется как часть последовательности базового использования.
В фазе 1 вы можете доставить базовый вариант использования, который соответствует требованиям в этой точке, а на этапе 2 добавятся дополнительные функциональные возможности, описанные в расширенном варианте использования. Это может содержать последовательности, которые всегда или иногда выполняются после доставки фазы 2 (опять-таки вопреки распространенному заблуждению).
Его можно использовать для извлечения подпоследовательностей базового варианта использования, особенно когда они представляют собой "исключительное сложное поведение с его собственными альтернативными потоками".

Один важный аспект, который следует учитывать, заключается в том, что расширяющийся вариант использования может "вставлять поведение в несколько мест в поток базовых вариантов использования, а не только в одном месте в качестве включенного варианта использования. По этой причине маловероятно, что расширенный вариант использования будет подходящим для расширения более чем одного базового варианта использования.

Что касается зависимости, расширяемый вариант использования зависит от базового варианта использования и снова является однонаправленной зависимостью, то есть базовый вариант использования не нуждается в какой-либо ссылке на расширяющийся вариант использования в последовательности. Это не значит, что вы не можете продемонстрировать точки расширения или добавить x-ref в расширяющийся вариант использования в другом месте шаблона, но базовый вариант использования должен иметь возможность работать без расширяющегося варианта использования.

РЕЗЮМЕ

Я надеюсь, что Ive показал, что распространенное заблуждение "включает в себя всегда, распространяется иногда" либо неправильно, либо, в лучшем случае, упрощенно. Эта версия на самом деле имеет смысл, если вы рассмотрите все проблемы, связанные с направленностью стрелок, которые представляет собой неправильное представление, - в правильной модели его просто зависимость и не может измениться, если вы реорганизуете содержимое прецедентов.

Ответ 3

Я часто использую это, чтобы запомнить два:

Мой прецедент: я еду в город.

включает в себя → привод автомобиля

extends → заполнить бензин

"Заполнить бензин" может не потребоваться в любое время, но может потребоваться необязательно в зависимости от количества бензина, оставленного в автомобиле. "Вождение автомобиля" является обязательным условием, поэтому я включаю в себя.

Ответ 4

Случаи использования используются для документирования поведения, например. ответьте на этот вопрос.

Поведение расширяет другое, если оно дополнительно, но не обязательно является частью поведения, например. исследуйте ответ.

Также обратите внимание, что исследование ответа не имеет большого смысла, если вы не пытаетесь ответить на вопрос.

Поведение включено в другое, если оно является частью поведения включения, например. войдите в стек обмена.

Чтобы пояснить, иллюстрация верна, только если вы хотите ответить здесь в переполнении стека:).

Это технические определения из UML 2.5 страницы 671-672.

Я подчеркнул, что я считаю важными.

Расширяет

Расширение - это отношение от расширяющегося UseCase (расширение) к расширенной UseCase (extendedCase), которая указывает как и когда поведение, определенное в расширяющемся UseCase, может быть вставлено в поведение, определенное в расширенном UseCase. Расширение происходит в одной или нескольких конкретных точках расширения, определенных в расширенной UseCase.

Расширение предназначено для использования при добавлении дополнительного поведения, которое должно быть добавлено, возможно условно, к поведению определенных в одном или нескольких UseCases.

расширенный UseCase определяется независимо от расширения UseCase и имеет смысл независимо от расширения UseCase. С другой стороны, расширение UseCase обычно определяет поведение, которое не обязательно может быть значимым само по себе. Вместо этого расширяемый UseCase определяет набор модульных приращений поведения, которые увеличивают выполнение расширенной UseCase при определенных условиях.

...

Включает в себя

Include - это DirectedRelationship между двумя UseCases, что указывает на то, что поведение включенного UseCase (дополнение) вставлен в поведение включенного UseCase (includeCase). Это также своего рода NamedElement, так что он может иметь имя в контексте его использования UseCase (includeCase). Включение UseCase может зависеть от изменений, выполнение включенного UseCase. Включенный UseCase должен быть доступен для поведения включенного UseCase полностью описано.

Отношение Include предназначено для использования, когда есть общие части поведения двух или более UseCases. Эта общая часть затем извлекается в отдельную UseCase, которая будет включена всеми базовыми UseCases, имеющими эту общую часть. Поскольку первичное использование отношения Include заключается в повторном использовании общих частей, что осталось в базе данных . UseCase обычно не завершается в сам, но зависит от включенных частей, которые должны быть значимыми. Это отражается в направлении отношения, что указывает на то, что base UseCase зависит от добавления, но не наоборот.

...

Ответ 5

Я думаю, что важно понимать намерение включать и расширять:

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

Это читается как:

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

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

Резюме:
Include = повторное использование функциональности
Extends = новая и/или необязательная функциональность

Вы чаще всего найдете второе использование (то есть необязательную функциональность) расширений, потому что, если функциональность не является необязательной, то в большинстве случаев она встроена в сам прецедент, а не является расширением. По крайней мере, это был мой опыт. (Julian C указывает, что вы иногда видите, что 1-е использование (т.е. Добавление новых функций) продолжается, когда проект входит в него 2-й этап).

Ответ 6

Позвольте сделать это более понятным. Мы используем include каждый раз, когда хотим выразить тот факт, что существование одного дела зависит от существования другого.

ПРИМЕРЫ:

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

Пользователь не может скачать с сайта, пока материал не был загружен. Так что я не могу скачать, если ничего не было загружено.

Ты понял?

Это об условном следствии. Я не могу сделать это, если раньше я этого не делал.

По крайней мере, я думаю, что это правильный способ использования Include. Я склонен думать, что пример с ноутбуком и гарантией сверху - самый убедительный!

Ответ 7

Я думаю, что объяснение msdn здесь довольно легко понять.

Включить [5]

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

Расширить [6]

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

Ответ 8

всякий раз, когда есть предпосылки для использования usecase, перейдите для include.

для usecases, имеющих аутентификацию, в худшем случае, или необязательные, затем для расширения.

пример: для случая использования в поисках приема, назначения, бронирования билетов ВЫ ДОЛЖНЫ ЗАПОЛНАТЬ ФОРМУ (форма регистрации или обратной связи).... это то, куда входит.

Например: для примера использования, подтверждающего логин или вход в вашу учетную запись, ваша аутентификация является обязательной. Также подумайте о наихудших сценариях. Например, возвращая книгу с прекрасным. НЕТ, получая оговорку. Платеж за счет ПОСЛЕ DUE DATE..Это место, где нужно играть...

не следует использовать include и расширяться на диаграммах.

СОХРАНЯЙТЕ ЭТО ПРОСТОЕ СЕРЕБРО!!!

Ответ 9

"Include" используется для расширения базового варианта использования и является обязательным условием, то есть включенный запуск использования должен выполняться успешно, чтобы завершить базовое использование.

например. Рассмотрим случай службы электронной почты, здесь "Вход" является включенным прецедентом, который должен быть запущен для отправки электронной почты (базовый вариант использования)

"Исключить", с другой стороны, является необязательным вариантом использования, который расширяет базовый прецедент, базовый прецедент может успешно работать даже без вызова/вызова расширенного варианта использования.

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

Ответ 10

Также будьте осторожны с UML-версией: уже давно существует, что < < использует → и < включает → заменены на < включают в себя → и < расширяет → на < expand → И обобщение.
Для меня это часто вводит в заблуждение: например, сообщение Stephanie и ссылка относятся к старой версии:

При оплате товара вы можете оплатить доставку, оплатить с помощью PayPal или оплатить карточкой. Все это является альтернативой варианту использования "платить за товар". Я могу выбрать любой из этих вариантов в зависимости от моих предпочтений.

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

Ответ 11

Упростить,

для include

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

Типичный пример: между логином и проверкой пароля

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

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

для extend

Когда базовый вариант использования выполняется, расширенный вариант использования выполняется только ИНОГДА
Расширенный вариант использования будет происходить только при соблюдении определенных критериев.

Типичный пример: между входом в систему и отображением сообщения об ошибке (только иногда случается)

(логин) < --- << extend >> --- (показать сообщение об ошибке)

"Показывать сообщение об ошибке" происходит иногда, когда процесс входа в систему не удалось.

Ответ 12

Это отличный ресурс с большим объяснением: Что входит в прецедент? Что такое расширение в прецеденте?

Расширение использования обычно определяет необязательное поведение. Это независимый расширяющийся вариант использования

Включить использование для извлечения общих частей поведения двух или более случаев использования

Ответ 13

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

<include> включен в базовый класс, т.е. является обязательным использовать <include> в вашем случае использования, иначе он будет считаться неполным.

например:

В конструкции банкомата (по мнению пользователей):

1: Снятие средств, внесение наличных денег и проверка учетной записи происходит под <extend>, потому что это зависит от пользователя, нужно ли снимать или депонировать или проверять. Это необязательные вещи, которые пользователь делает.

2: "Введите PIN-код, поместив карточку, извлекая карточку", это то, что подпадает под <include>, потому что пользователь должен и должен поместить карту и ввести действительный PIN-код для проверки.

Ответ 14

Расширения используется, когда вы понимаете, что ваш прецедент слишком сложный. Таким образом, вы извлекаете сложные шаги в свои собственные "расширительные" варианты использования.

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

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

Ответ 15

Элементы диаграммы

Актеры: Также называются Ролями. Имя и стереотип актера можно изменить на вкладке "Свойства".
Наследование: Уточнение отношений между актерами. Это отношение может носить название и стереотип.
Случаи использования: они могут иметь точки расширения.
Точки расширения: это определяет место, где можно добавить расширение.
Ассоциации: между ролями и прецедентами. Полезно давать ассоциации, говорящие имена.
Зависимости: между вариантами использования. Зависимости часто имеют стереотип, чтобы лучше определить роль зависимости. Чтобы выбрать стереотип, выберите зависимость от диаграммы или панели навигации, а затем измените стереотип на вкладке "Свойства". Существуют два специальных вида зависимостей: <<extend>> и <<include>>, для которых Poseidon предлагает собственные кнопки (см. Ниже).
Расширение отношения: однонаправленная связь между двумя вариантами использования. Пространственная связь между вариантом использования B и прецедентом A означает, что поведение B может быть включено в A.
Включение отношения: однонаправленная связь между двумя вариантами использования. Такая зависимость между вариантами использования A и B означает, что поведение B всегда включено в A.
Граница системы: граница системы фактически не реализована как элемент модели в Poseidon для UML. Вы можете просто нарисовать прямоугольник, отправить его на задний план и использовать его как системную границу, помещая все соответствующие варианты использования внутри прямоугольника.

Ответ 16

Я не рекомендую использовать это для запоминания двух:

Мой прецедент: я еду в город.

включает в себя → привод автомобиля

extends → заполнить бензин

Я предпочел бы использовать: Мой прецедент: я еду в город.

extends → вождение автомобиля

включает в себя → заполнение бензина

Am учил, что продолжение отношений продолжает поведение базового класса. Должны быть функциональные возможности базового класса. Соотношения включения, с другой стороны, сродни функциям, которые могут быть вызваны. Май выделен жирным шрифтом.

Это видно из повторное использование в манере использования

Ответ 17

Отношение include позволяет одному варианту использования включить шаги другого варианта использования.

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

Связь extend используется для добавления дополнительного шага к потоку прецедента, который обычно является необязательным шагом...

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

Однако обратите внимание, что пользователю не нужно выбирать Amazon Prime, это просто вариант, они могут игнорировать этот прецедент.

Ответ 18

Мне нравится думать о том, что "включает" в качестве необходимого предпосылки/сопровождения базового варианта использования. Это означает, что базовый вариант использования не может считаться полным без использования его использования. Я приведу пример веб-сайта электронной коммерции, который продает товары клиентам. Вы не можете заплатить за предмет без предварительного выбора этого предмета и поместить его в корзину. Это означает, что прецедент "Плата за элемент" включает "select item".

Существуют различные варианты расширений, но мне нравится думать об этом как о альтернативе, которая может или не может быть использована. Например - все еще на сайте электронной коммерции. При оплате товара вы можете оплатить доставку, оплатить с помощью PayPal или оплатить карточкой. Все это является альтернативой варианту использования "платить за товар". Я могу выбрать любой из этих вариантов в зависимости от моих предпочтений.

Для большей ясности и правил, связанных с примерами использования, прочитайте мою статью здесь:

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

Ответ 19

Здесь объясняется разница между ними. Но то, что не было объяснено, состоит в том, что <<include>> и <<extend>> просто не должны использоваться вообще.

Если вы читаете Bittner/Spence, вы знаете, что варианты использования - это синтез, а не анализ. Повторное использование прецедентов - это вздор. Это ясно показывает, что вы неправильно нарушили свой домен. Добавленная стоимость должна быть уникальной как таковой. Единственное повторное использование добавленной стоимости, которую я знаю, - это франшиза. Так что, если вы в бизнесе бургер, хорошо. Но везде ваша задача как BA - попытаться найти USP. И это должно быть представлено в хороших вариантах использования.

Всякий раз, когда я вижу людей, использующих одно из этих отношений, это когда они пытаются выполнять функциональную декомпозицию. И это неправильно.

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

В этом отношении поиск самостоятельных вариантов использования, которые включены или распространяются на другие варианты использования, очень маловероятен. В конце концов, вы можете использовать <<extend>>, чтобы показать возможность вашей системы, то есть какую-то лицензионную схему, которая позволяет включать варианты использования некоторых лицензий или опускать их. Но иначе - просто избегайте их.

Ответ 20

Если кто-то после прочтения обширной информации, представленной здесь, все еще не может обернуть вас вокруг этой концепции, я рекомендую вам посмотреть это превосходное видео (клик), опубликованное Lucidchart.