В чем разница между включением и расширением в диаграмме вариантов использования?
В чем разница между include а также extend в диаграмме варианта использования?
20 ответов
Расширение используется, когда вариант использования добавляет шаги в другой первоклассный вариант использования.
Например, представьте, что "снятие наличных" - это вариант использования банкомата. "Плата за оценку" будет расширять снятие наличных и описывать условную "точку расширения", которая создается, когда пользователь банкомата не осуществляет банковские операции в учреждении-владельце банкомата. Обратите внимание, что базовый вариант использования "Снять наличные" сам по себе, без расширения.
Включить используется для извлечения фрагментов варианта использования, которые дублируются в нескольких вариантах использования. Включенный вариант использования не может оставаться в одиночестве, и исходный вариант использования не является полным без включенного. Это следует использовать с осторожностью и только в тех случаях, когда дублирование является значительным и существует по замыслу (а не по совпадению).
Например, поток событий, который происходит в начале каждого случая использования банкомата (когда пользователь вставляет свою карту банкомата, вводит свой ПИН-код и показывает главное меню), был бы хорошим кандидатом для включения.
Это может быть спорным, но "включает в себя всегда, а иногда расширяет" - это очень распространенное заблуждение, которое почти сейчас перешло в де-факто. Вот правильный подход (на мой взгляд, и проверено на Джейкобсона, Фаулера, Лармена и 10 других ссылок).
Отношения это зависимости
Ключ к включению и расширению отношений прецедентов состоит в том, чтобы понять, что, как и в остальной части UML, пунктирная стрелка между вариантами использования является зависимой зависимостью. Я буду использовать термины "базовый", "включенный" и "расширяющий" для обозначения ролей вариантов использования.
включают
Базовый вариант использования зависит от включенных вариантов использования; без него / них базовый вариант использования является неполным, поскольку включенные варианты использования представляют подпоследовательности взаимодействия, которые могут происходить всегда ИЛИ иногда. (Это противоречит распространенному заблуждению по этому поводу: то, что предлагает ваш вариант использования, всегда происходит в основном сценарии, а иногда и в альтернативных потоках, просто зависит от того, что вы выбрали в качестве основного сценария; варианты использования могут быть легко реструктурированы для представления другого потока как основной сценарий и это не должно иметь значения).
В наилучшей практике односторонней зависимости базовый вариант использования знает (и ссылается на) включенный вариант использования, но включенный вариант использования не должен "знать" о базовом сценарии использования. Вот почему включенные варианты использования могут быть: а) базовыми вариантами использования сами по себе и б) распределены между несколькими базовыми вариантами использования.
простираться
Расширяемый вариант использования зависит от базового варианта использования; это буквально расширяет поведение, описанное в базовом сценарии использования. Базовый вариант использования должен представлять собой полностью функциональный вариант использования сам по себе ("конечно, включает в себя") без дополнительной функциональности расширенного варианта использования.
Расширение вариантов использования может быть использовано в нескольких ситуациях:
- Базовый вариант использования представляет функциональность "должен иметь" проекта, в то время как расширенный вариант использования представляет необязательное (следует / может / хотеть) поведение. Здесь уместен термин необязательный - необязательный, создавать ли / доставлять, а не необязательный, иногда ли он выполняется как часть последовательности базового варианта использования.
- На этапе 1 вы можете предоставить базовый вариант использования, который соответствует требованиям на этом этапе, а на этапе 2 добавятся дополнительные функциональные возможности, описанные в расширенном сценарии использования. Это может содержать последовательности, которые всегда или иногда выполняются после фазы 2 (опять-таки вопреки распространенному заблуждению).
- Его можно использовать для извлечения подпоследовательностей базового варианта использования, особенно когда они представляют "исключительное" сложное поведение со своими собственными альтернативными потоками.
Один важный аспект, который следует учитывать, заключается в том, что расширяющий вариант использования может "вставлять" поведение в нескольких местах в потоке базового варианта использования, а не только в одном месте, как это делает включенный вариант использования. По этой причине весьма маловероятно, что расширенный вариант использования будет подходящим для расширения более чем одного базового варианта использования.
Что касается зависимости, то расширенный вариант использования зависит от базового варианта использования и снова является односторонней зависимостью, то есть базовый вариант использования не нуждается в какой-либо ссылке на расширенный вариант использования в последовательности. Это не означает, что вы не можете продемонстрировать точки расширения или добавить 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 (incl в том числе). Это также своего рода NamedElement, так что он может иметь имя в контексте его собственной UseCase (включая Case). Включение UseCase может зависеть от изменений, произведенных выполнением включенного UseCase. Включенный UseCase должен быть доступен для полного описания поведения включаемого UseCase.
Отношение "Включить" предназначено для использования, когда есть общие части поведения двух или более вариантов использования. Эта общая часть затем извлекается в отдельный UseCase, чтобы быть включенным во все базовые UseCase, имеющие эту общую часть. Поскольку основное использование отношения "Включить" предназначено для повторного использования общих частей, то, что остается в базовом UseCase, обычно не является полным само по себе, а зависит от включенных частей, чтобы иметь смысл. Это отражается в направлении взаимосвязи, указывая на то, что базовый UseCase зависит от дополнения, а не наоборот.
...
Упростить,
за include
- Когда базовый вариант использования выполняется, включенный вариант использования выполняется ВСЕ.
- Базовый вариант использования требует завершения включенного варианта использования для его завершения.
Типичный пример: между логином и проверкой пароля
(логин) --- << включить >> ---> (подтвердить пароль)
для успешного входа в систему "проверка пароля" также должна быть успешной.
за extend
- Когда базовый вариант использования выполняется, расширенный вариант использования выполняется только ИНОГДА
- Расширенный вариант использования будет происходить только при соблюдении определенных критериев.
Типичный пример: между входом в систему и отображением сообщения об ошибке (только иногда случается)
(логин) <--- << extend >> --- (показать сообщение об ошибке)
"Показывать сообщение об ошибке" происходит иногда, когда процесс входа в систему не удалось.
Я думаю, что важно понимать намерение включает в себя и расширяет:
"Отношение включения предназначено для повторного использования поведения, моделируемого другим вариантом использования, тогда как отношение расширения предназначено для добавления деталей в существующие варианты использования, а также для моделирования дополнительных системных служб" (Overgaard and Palmkvist, Use Cases: Patterns and Blueprints. Addison. Уэсли, 2004).
Это читается мне как:
Включить = повторное использование функциональности (т. Е. Включенная функциональность используется или может использоваться в другом месте системы). Таким образом, include обозначает зависимость от другого варианта использования.
Расширяет = добавление (не повторное использование) функциональных возможностей, а также любых дополнительных функциональных возможностей. Расширения поэтому могут обозначать одну из двух вещей:
1. добавление новых функций / возможностей в вариант использования (опционально или нет)
2. любые дополнительные варианты использования (существующие или нет).
Резюме:
Включить = повторное использование функциональности
Расширяет = новые и / или дополнительные функции
Чаще всего вы найдете 2-е использование (то есть необязательную функциональность) расширений, потому что если функциональность не является необязательной, то в большинстве случаев она встроена в сам вариант использования, а не является расширением. По крайней мере, это был мой опыт. (Джулиан С. указывает, что вы иногда видите 1-е использование (то есть добавление новых функций) расширений, когда проект входит во 2-ю фазу).
Я думаю, что объяснение MSDN здесь довольно легко понять.
Включить [5]
Включающий вариант использования вызывает или вызывает включенный вариант. Включение используется, чтобы показать, как сценарий использования разбивается на более мелкие этапы. Включенный вариант использования находится на конце стрелки.
Расширить [6]
Между тем, расширенный вариант использования добавляет цели и шаги в расширенный вариант использования. Расширения работают только при определенных условиях. Расширенный вариант использования находится на конце стрелки.
Давайте сделаем это понятнее. Мы используем include каждый раз мы хотим выразить тот факт, что существование одного случая зависит от существования другого.
ПРИМЕРЫ:
Пользователь может делать покупки онлайн только после того, как он вошел в свою учетную запись. Другими словами, он не может делать покупки, пока не войдет в свою учетную запись.
Пользователь не может скачать с сайта, пока материал не был загружен. Так что я не могу скачать, если ничего не было загружено.
Ты понял?
Это об условных последствиях. Я не могу сделать это, если раньше я этого не делал.
По крайней мере, я думаю, что это правильный способ, которым мы используем Include, Я склонен думать, что пример с ноутбуком и гарантией сверху - самый убедительный!
Тогда, когда есть предпосылки для прецедента, включите include.
для сценариев использования, имеющих аутентификацию, наихудший сценарий или необязательных, перейдите на расширение.
Например: для случая использования запроса на прием, встречу, бронирование билета ВЫ ДОЛЖНЫ ЗАПОЛНИТЬ ФОРМУ (регистрационную форму или форму обратной связи).... вот, что включает в себя..
пример: для варианта использования, подтверждающего вход в систему или вход в вашу учетную запись, ваша аутентификация является обязательной. Также следует подумать о сценариях наихудшего случая. Например, возвращать книгу с штрафом. НЕ получайте бронирование. Оплачиваете счет. ПОСЛЕ ОТЧЕТНОЙ ДАТЫ. Это где простирается, чтобы играть...
не злоупотребляйте включением и расширением диаграмм.
Держите его просто глупо!
И то и другое <include> а также <extend> зависят от базового класса, но <extend> является необязательным, т. е. он является производным от базового класса, но, с точки зрения пользователей, он может использоваться или не использоваться.
<include> включен в базовый класс, т. е. обязательно использовать <include> в вашем случае использования, иначе это будет считаться неполным.
например:
В конструкции банкомата (по мнению пользователей):
1: снятие, внесение наличных и проверка счета <extend> потому что это зависит от пользователя, чтобы снять или внести или проверить. Это необязательные вещи, которые делает пользователь.
2: "Введите пин-код, поместите карточку, извлеките карточку". <include> потому что пользователь должен и должен поместить карту и ввести действительный пин-код для проверки.
Также остерегайтесь UML-версии: прошло уже много времени, когда << использует >> и << включает >> были заменены на << include >>, а << extends >> на << extended >> и обобщение.
Для меня это часто вводит в заблуждение: в качестве примера пост и ссылка Стефани о старой версии:
При оплате товара вы можете оплатить доставку, оплатить через PayPal или оплатить картой. Все это альтернативы сценарию использования "Оплата за товар". Я могу выбрать любой из этих вариантов в зависимости от моих предпочтений.
На самом деле нет никакой альтернативы "платить за товар"! В настоящее время в UML "оплата по доставке" - это расширение, а "оплата с помощью PayPal"/"оплата по карте" - это специализации.
"Включить" используется для расширения базового варианта использования и является обязательным условием, т. Е. Запуск включенного сценария должен успешно выполняться для завершения базового использования.
Например, рассмотрим случай службы электронной почты, здесь "Логин" - это включенный вариант использования, который необходимо запустить для отправки электронной почты (базовый вариант использования)
"Исключить", с другой стороны, является необязательным вариантом использования, который расширяет базовый сценарий использования, базовый сценарий использования может успешно выполняться даже без вызова / вызова расширяющего варианта использования.
Например, рассматривайте "Покупку ноутбука" в качестве базового варианта использования и "Дополнительную гарантию" в качестве расширенного варианта использования, здесь вы можете запустить базовый сценарий "Покупка ноутбука" даже без получения дополнительной гарантии.
Это отличный ресурс с хорошим объяснением: что входит в сценарий использования? Что такое расширение в случае использования?
Расширение варианта использования обычно определяет необязательное поведение. Это не зависит от расширяющегося варианта использования
Включить используется для извлечения общих частей поведения двух или более вариантов использования
Я не рекомендую использовать это, чтобы помнить два:
Мой вариант использования: я иду в город.
включает в себя -> водить машину
расширяет -> заправить бензин
Я бы предпочел, чтобы вы использовали: Мой вариант использования: я иду в город.
расширяет -> вождение автомобиля
включает в себя -> заправить бензин
Учили, что расширение отношений продолжает поведение базового класса. Функции базового класса должны быть там. Отношение включения, с другой стороны, сродни функциям, которые могут быть вызваны. Май выделен жирным шрифтом
Это видно из повторного использования agilemodeling в моделях прецедентов
Элементы диаграммы
Актеры: также упоминается как роли. Имя и стереотип актера можно изменить на вкладке "Свойства".
Наследование: уточнение отношений между субъектами. Это отношение может носить имя и стереотип.
Варианты использования: у них могут быть точки расширения.
Точки расширения: это определяет место, где можно добавить расширение.
Ассоциации: между ролями и вариантами использования. Полезно давать ассоциации говорящим именам.
Зависимости: между вариантами использования. Зависимости часто имеют стереотип, чтобы лучше определить роль зависимости. Чтобы выбрать стереотип, выберите зависимость на диаграмме или в панели навигации, затем измените стереотип на вкладке Свойства. Существует два особых вида зависимостей:
<<extend>>а также<<include>>, для которого Посейдон предлагает собственные кнопки (см. ниже).Расширьте отношения: однонаправленные отношения между двумя вариантами использования. Расширение отношения между вариантом использования B и вариантом использования A означает, что поведение B может быть включено в A.
Включите отношения: однонаправленные отношения между двумя вариантами использования. Такая связь между вариантами использования A и B означает, что поведение B всегда включено в A.
Граница системы: Граница системы фактически не реализована как элемент модели в Посейдоне для UML. Вы можете просто нарисовать прямоугольник, отправить его на задний план и использовать его в качестве системной границы, поместив все соответствующие варианты использования внутри прямоугольника.
Разница между ними была объяснена здесь. Но что не было объяснено тем фактом, что <<include>> а также <<extend>> просто не должен использоваться вообще.
Если вы читаете "Биттнер / Спенс", вы знаете, что варианты использования - это синтез, а не анализ. Повторное использование вариантов использования - это чепуха. Это ясно показывает, что вы неправильно вырезали свой домен. Добавленная стоимость должна быть уникальной как таковой. Единственное повторное использование добавленной стоимости, которое я знаю, это франшиза. Так что, если вы занимаетесь гамбургерами, хорошо. Но повсюду ваша задача как BA - попытаться найти USP. И это должно быть представлено в хороших случаях использования.
Всякий раз, когда я вижу людей, использующих одно из этих отношений, это происходит, когда они пытаются выполнить функциональную декомпозицию. И это совершенно неправильно.
Проще говоря: если вы можете без колебаний ответить своему боссу "Я сделал...", то "..." - это ваш вариант использования, поскольку у вас есть деньги для этого. (Это также прояснит, что "логин" вообще не является вариантом использования.)
В этом отношении поиск самостоятельных вариантов использования, которые включены или расширяют другие варианты использования, очень маловероятен. В конце концов вы можете использовать <<extend>> показать опциональность вашей системы, то есть некоторую схему лицензирования, которая позволяет включать варианты использования для некоторых лицензий или опускать их. Но в остальном - просто избегайте их.
Отношение включения позволяет одному варианту использования включать этапы другого варианта использования.
Например, предположим, что у вас есть учетная запись Amazon и вы хотите проверить заказ, но невозможно проверить заказ без предварительного входа в свою учетную запись. Так что поток событий хотел бы так...
Отношение расширения используется для добавления дополнительного шага к потоку сценария использования, который обычно является необязательным шагом...
Представьте, что мы все еще говорим о вашем аккаунте Amazon. Предположим, что базовый вариант - Order, а вариант использования расширения - Amazon Prime. Пользователь может просто регулярно заказывать товар или же он может выбрать Amazon Prime, чтобы его заказ доставлялся быстрее при более высокой стоимости.
Тем не менее, обратите внимание, что пользователь не должен выбирать Amazon Prime, это просто вариант, он может игнорировать этот вариант использования.
Extends используется, когда вы понимаете, что ваш вариант использования слишком сложен. Таким образом, вы извлекаете сложные шаги в свои собственные "дополнительные" варианты использования.
Включает в себя используется, когда вы видите общее поведение в двух случаях использования. Таким образом, вы абстрагируете общее поведение в отдельный "абстрактный" вариант использования.
(ссылка: Джеффри Л. Уиттен, Лонни Д. Бентли, Системный анализ и методы проектирования, McGraw-Hill/Irwin, 2007)
Мне нравится думать о "включает" как необходимую предпосылку / сопровождение базового варианта использования. Это означает, что базовый вариант использования нельзя считать завершенным без включенного в него варианта использования. Я приведу пример сайта электронной коммерции, который продает товары покупателям. Вы не можете оплатить товар, не выбрав его и не поместив в корзину. Это подразумевает, что сценарий использования "Оплата товара" включает в себя "выбор товара".
Существуют различные варианты использования расширений, но мне нравится думать об этом как об альтернативе, которая может использоваться или не использоваться. Например - еще на сайте электронной коммерции. При оплате товара вы можете оплатить доставку, оплатить через PayPal или оплатить картой. Все это альтернативы сценарию использования "Оплата за товар". Я могу выбрать любой из этих вариантов в зависимости от моих предпочтений.
Для большей ясности и правил, связанных с вариантами использования, прочитайте мою статью здесь:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics
Насколько я помню, это видеоигры. Например, (ниже не для 100% всех случаев, а просто пример варианта использования)
Расширяет: главное меню расширяет некоторые функции, что означает, что у них есть некоторые функции, но их не нужно нажимать.
Включает в себя: чтобы стрелять из оружия в видеоигре, вы должны сначала иметь его.