Обобщение прецедентов по сравнению с расширением

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

Обобщающее изображение варианта использования

Используйте изображение расширения прецедента

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

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

void makePayment(const PaymentDetails* pd)
{
   pd->pay();
}

в отличие от

void makePayment(const PaymentDetails* pd)
{
   switch(pd->type)
   {
       case EFT:
                payViaEFT(pd); 
                break;
       case PAYPAL:
                payViaPayPal(pd); 
                break;
       case CREDITCARD:
                payViaCreditCard(pd); 
                break;
   }
}

Не слишком ли ранняя стадия варианта использования для моделирования таких конкретных проблем реализации? Для этого есть гораздо более подходящие UML-диаграммы. Есть ли жесткое и быстрое правило относительно того, какой из двух использовать, и если да, то какой?


use-case uml
person DuncanACoulter    schedule 28.02.2013    source источник
comment
Обе реализации моделируют одну и ту же проблему. Они не связаны с той или иной диаграммой UC. Полиморфный гораздо более желателен, так как он проще, его легче расширять и он менее подвержен человеческим ошибкам.   -  person André Willik Valenti    schedule 04.05.2015

Ответы (3)


arrow_upward
16
arrow_downward

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

Это правда.

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

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

Не слишком ли ранняя стадия варианта использования для моделирования таких конкретных проблем реализации?

Что ж, как указано выше, UML не требует какой-либо конкретной реализации. Однако здесь вы собираете некоторые важные функциональные требования, которые могут сильно повлиять на ваше расписание и рабочую нагрузку. («Оплата кредитной картой» намного сложнее, чем «оплата заранее банковским переводом»). Таким образом, вы стремитесь уловить это, но остаетесь открытыми для различных подходов к решению.

Для этого есть гораздо более подходящие UML-диаграммы.

Вы действительно можете использовать их параллельно :), так как это разные взгляды на одну и ту же тему.

Есть ли жесткое и быстрое правило относительно того, какой из двух использовать, и если да, то какой?

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

person observer    schedule 28.02.2013

arrow_upward
10
arrow_downward

При моделировании с отношением расширения вариант использования расширения (оплата через xxx) выполняется, когда вариант использования расширения (выполнение платежа) находится в точном местоположении (заданном точкой расширения, типом платежа), если выполняется условие для такого отношения расширения. (например, для «Оплатить через Paypal» условием будет payment_type=PAYPAL). В этой модели «Оплата через Paypal» касается только деталей завершения платежной транзакции в Paypal, а «Выполнение платежа» определяет все действия, которые не зависят от способа оплаты (например, вычисление общей суммы и сохранение платежа). результат транзакции после ее совершения).

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

Расширение варианта использования не означает, что альтернативы должны быть жестко запрограммированы. Действительно, ваш первый пример также является допустимой реализацией отношения расширения, поскольку pd->pay(pd) будет вызывать различное поведение в зависимости от выбранного типа платежа. Фактически, диаграммы вариантов использования моделируют предполагаемую работу системы, в то время как низкоуровневые детали реализации лучше указываются на диаграммах действий.

person Javier    schedule 28.02.2013

arrow_upward
5
arrow_downward

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

Вы можете посмотреть на отношение «является», чтобы определить, какое использовать. Оплата через PayPal — это «оплата», особый способ оплаты. Введите код скидки не является. Это то, что вы можете сделать дополнительно во время оплаты.

person BobRodes    schedule 10.12.2014
comment
Я вижу, что вы говорите. Сделать платеж сам по себе не является полным, поэтому наиболее естественным отношением для использования будет обобщение (которое я в любом случае предпочитаю). Однако использование обобщения, по-видимому, означает, что одновременное использование нескольких форм оплаты невозможно. Некоторые люди говорят, что добавление быть полезным, чтобы избежать этих проблем. Твои мысли? - person DuncanACoulter; 22.12.2014
comment
Я посмотрел проблему, как указано автором в вашей ссылке. Есть простое решение. Если подумать, платеж двумя способами — это фактически два платежа. Автор зацикливается на идее, что несколько способов оплаты должны быть одним проходом через вариант использования «совершить платеж». Вы можете сделать один проход для каждого способа оплаты. Если вы хотите связать несколько платежных транзакций в один логический платеж, расширьте вариант использования «Внести платеж», добавив вариант использования «Обработка нескольких способов оплаты» или что-то подобное, который связывает несколько проходов через «Внести платеж». - person BobRodes; 22.12.2014
comment
Кроме того, хотя сейчас я вижу смысл в возможном использовании расширений для обработки нескольких платежей, я все же думаю, что использование модели обобщения является более точным. Использование расширений не так четко различает один и несколько способов оплаты. - person BobRodes; 22.12.2014
comment
Спасибо @BobRodes. Я согласен с тем, что обобщение — это правильный путь, я искал правило (эмпирическое), которое указывает, когда один подход более уместен, чем другой. - person DuncanACoulter; 04.01.2015