uml - puntos - Uso generalización de casos versus extensión.

include casos de uso

Question

Los diagramas de casos de uso de UML permiten dos formas aparentemente equivalentes para mostrar que un caso de uso dado puede realizarse de varias maneras diferentes, es decir, generalizaciones de casos de uso en lugar de extensiones de casos de uso . He visto el siguiente ejemplo básicamente modelado utilizando cualquiera de los dos enfoques con la misma frecuencia, a veces dentro de una sola fuente.

En mi opinión, una extensión es una relación más débil que la generalización, ya que una sustitución directa del caso de uso especializado para el caso base debe ser posible en generalización pero no necesariamente en extensiones.

Me parece que la generalización implica que se desea una implementación polimórfica mientras que la extensión implica que se utilizará alguna estructura de ramificación.

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

Opuesto a

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

¿No es la etapa de caso de uso demasiado pronto para que se puedan modelar dichas preocupaciones específicas de implementación? Hay diagramas UML mucho más apropiados para eso. ¿Existe una regla estricta y rápida con respecto a cuál de los dos usar y, en caso afirmativo, cuál es?

Answer 1

En mi opinión, una extensión es una relación más débil que la generalización, ya que una sustitución directa del caso de uso especializado para el caso base debe ser posible en generalización pero no necesariamente en extensiones.

Eso es verdad.

Me parece que la generalización implica que se desea una implementación polimórfica mientras que la extensión implica que se utilizará alguna estructura de ramificación.

El diagrama no dicta ninguna implementación. Sin embargo, puedes interpretar una pista del diagrama por ti mismo. UML permanece independiente del lenguaje y la solución allí.

¿No es la etapa de caso de uso demasiado pronto para que se puedan modelar dichas preocupaciones específicas de implementación?

Bueno, como se indicó anteriormente, UML no impone ningún tipo específico de implementación. Sin embargo, está reuniendo algunos requisitos funcionales importantes que podrían influir en gran medida en su horario y carga de trabajo. ("Pagar con tarjeta de crédito" es mucho más complejo de manejar que "pagar por adelantado mediante transferencia bancaria"). Así que se esforzaría por capturar eso, pero permanecería abierto a diferentes enfoques de solución.

Hay diagramas UML mucho más apropiados para eso.

Realmente puedes usarlos en paralelo :) ya que son vistas diferentes sobre el mismo tema.

¿Existe una regla estricta y rápida con respecto a cuál de los dos usar y, en caso afirmativo, cuál es?

Prefiero la generalización en este caso porque, de hecho, las extensiones sugieren falsamente que podría haber una manera de pagar sin usar ninguna de las tres opciones nombradas. Como te has indicado.

Answer 2

Cuando se modela con una relación extendida, el caso de uso extendido (pago a través de xxx) se ejecuta cuando el caso de uso extendido (hacer pago) se encuentra en una ubicación precisa (dada por el punto de extensión, tipo de pago) si se cumple la condición para dicha relación extendida (Por ejemplo, para "Pay via Paypal", la condición sería payment_type = PAYPAL). En este modelo, "Pay via Paypal" solo se ocupa de los detalles de completar una transacción de pago con Paypal, mientras que "Make Payment" especifica todos los comportamientos que son independientes del método de pago (como calcular el monto total y guardar el resultado de la transacción una vez que se realizó).

Por otro lado, la generalización (que se define no solo para los casos de uso, sino también para cualquier clasificador) es un concepto más amplio, ya que no detalla (a nivel de diagrama) los detalles de cuándo y cómo se ejecutan los comportamientos especializados. Si "Pay via Paypal" fuera una especialización de "Make Payment", se redefiniría el comportamiento de "Make Payment", que podría ser sustancialmente diferente del comportamiento de "Pay via credit card".

Ser un caso de uso extendido no significa que las alternativas tengan que estar codificadas. De hecho, su primer ejemplo también es una implementación válida de una relación extendida, ya que pd->pay(pd) invocará diferentes comportamientos dependiendo del tipo de pago seleccionado. En realidad, los diagramas de casos de uso modelan lo que se supone que debe hacer un sistema , mientras que los detalles de implementación de bajo nivel se especifican mejor en los diagramas de actividad.

Answer 3

Un ejemplo de una extensión sería un caso de uso "Introducir código de descuento". Ingresar un código de descuento tiene que ver con hacer un pago, pero no tiene que ingresar uno para poder realizar el pago.

Puede ver la relación "es un" para tomar la determinación de cuál usar. Pagar con PayPal "es un" pago, una forma específica de realizar un pago. Introduzca el código de descuento no es. Es algo adicional que puedes hacer mientras haces un pago.