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

В чем разница между includeи extendв диаграмме вариантов использования ?

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

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

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

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

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

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

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

включают

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

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

простираться

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

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

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

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

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

РЕЗЮМЕ

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

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

Мой вариант использования: я иду в город.

включает в себя -> водить машину

расширяет -> заправить бензин

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

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

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

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

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

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

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

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

Расширяет

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

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

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

...

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

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

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

...

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

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

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

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

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

Резюме:
Включить = повторное использование функциональности
Расширения = новые и / или дополнительные функции

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

Чтобы упростить,

за include

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

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

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

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

за extend

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

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

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

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

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

Включить [5]

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

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

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

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

ПРИМЕРЫ:

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

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

Ты понял?

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

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

тогда, когда есть предпосылки для прецедента, переходите к включению.

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

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

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

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

Держите его просто глупо!

Также остерегайтесь UML-версии: прошло уже много времени, когда << использует >> и << включает >> были заменены на << include >>, а << extends >> на << extended >> и обобщение .
Для меня это часто вводит в заблуждение: в качестве примера пост и ссылка Стефани о старой версии:

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

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

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

Например, рассмотрим случай службы электронной почты, здесь «Логин» - это включенный вариант использования, который необходимо запустить для отправки электронной почты (базовый вариант использования)

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

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

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

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

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

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

• Актеры: также упоминается как роли. Имя и стереотип актера можно изменить на вкладке «Свойства».

• Наследование: уточнение отношений между субъектами. Это отношение может носить имя и стереотип.

• Варианты использования: у них могут быть точки расширения.

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

• Ассоциации: между ролями и вариантами использования. Полезно давать ассоциации говорящим именам.

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

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

• Включите отношения: однонаправленные отношения между двумя вариантами использования. Такая связь между вариантами использования A и B означает, что поведение B всегда включено в A.

• Граница системы: Граница системы фактически не реализована как элемент модели в Посейдоне для UML. Вы можете просто нарисовать прямоугольник, отправить его на задний план и использовать его в качестве системной границы, поместив все соответствующие варианты использования внутри прямоугольника.

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

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

например:

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

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

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

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

Мой вариант использования: я иду в город.

включает в себя -> водить машину

расширяет -> заправить бензин

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

расширяет -> вождение автомобиля

включает в себя -> заправить бензин

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

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

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

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

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

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

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

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

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

(ссылка: Джеффри Л. Уиттен, Лонни Д. Бентли, Системный анализ и методы проектирования, McGraw-Hill / Irwin, 2007)

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

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

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

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

Тем не менее, обратите внимание, что пользователю не нужно выбирать Amazon Prime, это всего лишь вариант, он может игнорировать этот вариант использования.

Мне нравится думать о «включает» как необходимую предпосылку / сопровождение базового варианта использования. Это означает, что базовый вариант использования нельзя считать завершенным без включенного в него варианта использования. Я приведу пример сайта электронной коммерции, который продает товары покупателям. Вы не можете оплатить товар, не выбрав его и не поместив в корзину. Это подразумевает, что вариант использования «Оплата за товар» включает в себя «выбор товара».

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

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

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