Использование диаграммы использования UML. Включить и расширить опции [дублировать]

Я думаю, что важно понимать намерение include и extends:

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

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

Include = повторное использование

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

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

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

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

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

ПРИМЕРЫ:

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

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

Получишь ли ты это?

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

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

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

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

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

include

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

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

extend

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

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

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

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

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

РЕЗЮМЕ

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

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

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

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

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

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

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

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

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

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

Например, представьте себе, что «Withdraw Cash» является прецедентом автоматизированного банкомата (ATM). «Оценка платы» будет расширять Withdraw Cash и описывать условную «точку добавочного номера», которая создается, когда пользователь ATM не берет банк в принадлежащем банкомате учреждении. Обратите внимание, что основной пример использования «Withdraw Cash» стоит отдельно, без расширения.

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

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

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

Включить [5]

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

Extend [6]

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

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

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

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

extends -> fill petrol

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

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

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

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

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

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

для include

1. Когда выполняется базовый вариант использования, включенный вариант использования выполняется EVERYTIME.

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

(логин) - базовый вариант использования, - & lt; включите >> ---> (проверьте пароль)

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

для extend

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

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

(login) & lt; --- & lt; extend >> --- (показать сообщение об ошибке)

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

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

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

(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Systems analysis & amp; design methods, McGraw-Hill / Irwin, 2007 ) [/ д2]

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

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

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

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

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

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

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

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

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

http: // businessanalystlearnings. ком / ба-технологии / 2013 / 2/20 / использование регистра-схема-в-Основы

Также будьте осторожны с версией UML: уже давно существует, что & lt; использует >> и & lt; включает >> заменены на & lt; включают в себя >> и & lt; продолжается >> на & lt; простирайтесь >> И обобщение. Для меня это часто вводит в заблуждение: например, сообщение Стефани и ссылка о старой версии:

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

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

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

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

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

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

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

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

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

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

extends -> fill petrol

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

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

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

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

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

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

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

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

/ g22]

Расширение - это отношение расширенного 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, обычно не является само по себе, но зависит от включенных частей, которые должны быть значимыми. Это отражается в направлении отношения, что указывает на то, что базовая UseCase зависит от добавления, но не наоборот.

...

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

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

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

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

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

ХРАНИТЕ ЕГО ПРОСТОЙ СИЛЛИ !!!