Advanced Use Cases
 |
| DSN_XP y el modelado avanzado de casos de uso |
DSN_XP desde su versión 1.0 adoptó para efectos de modelado avanzado, el uso de UML como guía para la generación de documentos basados en el pensamiento visual y la necesidad de un modelo que represente los límites del proceso de abstracción.
Use Case
De todos los artefactos que hemos estudiado al desarmar las diversas escuelas de modelado de soluciones software y la historia del software, nos sentimos inmediatamente identificados con el modelo de casos uso, luego entenderíamos que esta naturalidad de nuestro confort en el uso de los casos de uso, se debía a nuestro razonamiento descendente proveniente de la programación estructurada e incluso de la programación orientada a la sintaxis y formatos con Fortran y Cobol, pasando por la programación dirigida por las etiquetas y/o subrutinas.
Cuando encontramos los casos de uso, notamos que consideraban dos dimensiones que más tarde darían forma a las perspectivas Software View y Business View, justamente por el uso de la palabra CASE que nos permitía encapsular observaciones en abstracciones delimitadas por la usabilidad que representaba el escenario observado y el conjunto de casos de control o comportamiento que se encapsulaban en esa observación.
¿Qué es un modelo de caso de uso?
Estudio realizado en base a este artículo que hacemos referencia por la importancia del modelo de casos de uso dentro de los requisitos de software. Comprender los fundamentos de los modelos de casos de uso y poder crear su propio modelo de casos de uso, como comprender ¿Qué es una especificación de casos de uso?, e intentar aplicar casos de uso y el modelado avanzado con los modelos de casos de uso.
Definición
El modelo de caso de uso se utiliza para definir los elementos y procesos centrales que componen un sistema. Los elementos clave se denominan "actores" y los procesos se denominan "casos de uso". El modelo de casos de uso muestra qué actores interactúan con cada caso de uso. Esta definición establece de qué se compone principalmente un modelo de casos de uso: actores y casos de uso.
Un modelo de caso de uso debe capturar los componentes funcionales del sistema. Realza los procesos comerciales dentro del sistema. Mientras recorre su sistema, aprenderá importantes atributos del sistema que captura en el modelo de caso de uso. Debido a que los modelos de casos de uso son simples por naturaleza, están libres de jerga técnica, los modelos de casos de uso son una excelente manera de generar flujos de guiones gráficos con los usuarios.
Los modelos de casos de uso tienen otra función fundamental. Los modelos de casos de uso definen los requisitos del sistema que se modela y ayudan a redactar los escenarios que se utilizarán posteriormente en las pruebas.
¿Qué es un modelo de caso de uso de UML (modelo de caso de uso) y cuándo debería utilizarlo?
Los modelos de casos de uso de UML se pueden utilizar para describir la funcionalidad de un sistema de forma horizontal. Es decir, en lugar de simplemente representar los detalles de las características individuales de su sistema, los modelos de casos de uso se pueden utilizar para mostrar toda su funcionalidad disponible. Sin embargo, es importante tener en cuenta que los modelos de casos de uso son fundamentalmente diferentes de los diagramas de secuencia o diagramas de flujo porque no intentan representar el orden o el número de veces que las acciones y subacciones del sistema deben ejecutarse. Hay varios ejemplos gráficos en estas preguntas frecuentes; es posible que desee examinarlos para familiarizarse con su aspecto.
Los modelos de casos de uso tienen solo 4 elementos principales:
- los actores con los que interactúa el sistema que está describiendo,
- el sistema en sí,
- los casos de uso o servicios que el sistema sabe cómo realizar y
- las líneas que representan las relaciones entre estos elementos.
Debe utilizar modelos de casos de uso para representar la funcionalidad de su sistema desde una perspectiva de arriba hacia abajo (es decir, de un vistazo, la funcionalidad del sistema es obvia, pero todas las descripciones están en un nivel muy alto. Más adelante se pueden agregar más detalles a la diagrama para dilucidar puntos interesantes en el comportamiento del sistema).
Ejemplo: Un modelo de caso de uso se adapta bien a la tarea de describir todas las cosas que se pueden hacer con un sistema de base de datos, por todas las personas que podrían usarlo (administradores, desarrolladores, personal de entrada de datos).
NO debe utilizar modelos de casos de uso para representar un comportamiento de excepción (cuando ocurren errores) o para intentar ilustrar la secuencia de pasos que se deben realizar para completar una tarea. Utilice diagramas de secuencia para mostrar estas características de diseño.
Ejemplo: Un modelo de caso de uso no sería adecuado para describir el protocolo de red TCP / IP, porque hay muchos casos de excepción, comportamientos de ramificación y funcionalidad condicional (¿Qué sucede cuando un paquete se pierde o se retrasa, qué pasa cuando la conexión se interrumpe? )
¿Cuáles son los componentes de un modelo de caso de uso?
Los componentes clave del modelo de casos de uso son los propios actores, los casos de uso vinculados a los actores, los límites donde se ubican los casos de uso y las asociaciones entre los componentes anteriores.
Al revisar el material a continuación y leer el ejemplo a continuación, debería poder obtener una buena comprensión para construir su propio modelo de caso de uso.
¿Cómo saber quiénes son los actores en un modelo de caso de uso?
Cuando se trabaja desde una tabla Acción / Respuesta, identificar los actores es fácil: las entidades cuyo comportamiento aparece en la columna “Acciones del actor” son los actores y las entidades cuyo comportamiento aparece en la columna “Respuesta del sistema” son componentes del sistema.
Si está trabajando desde una narrativa informal, un diagrama de secuencia o una descripción de escenario, los actores suelen ser aquellas entidades cuyo comportamiento no puede controlar o cambiar (es decir, agentes que no son parte del sistema que está construyendo o describiendo). los candidatos más obvios para los actores son los humanos en el sistema; excepto en casos raros cuando el sistema que está describiendo es en realidad un proceso humano (como un método específico para tratar con los clientes que los empleados deben seguir), los humanos con los que debe interactuar serán todos actores.
Si su sistema interactúa con otros sistemas (bases de datos, servidores mantenidos por otras personas, sistemas heredados), será mejor que los trate también como actores, ya que no es su comportamiento lo que está interesado en describir.
Ejemplo: al agregar un nuevo sistema de base de datos para administrar las finanzas de una empresa, su sistema probablemente tendrá que interactuar con su software de administración de inventario existente. Dado que usted no escribió este software, no tiene la intención de reemplazarlo y solo usa los servicios que proporciona, tiene sentido que ese sistema sea un actor.
¿Cómo sabe qué poner en el cuadro "Sistema" del modelo de caso de uso?
El cuadro del sistema solo aparece en el diagrama de nivel superior (recuerde que una descripción típica de caso de uso de UML estará compuesta por muchos diagramas y sub-diagramas) y debe contener óvalos de casos de uso, uno para cada servicio de nivel superior que proporciona su sistema. a sus actores.
Cualquier tipo de comportamiento interno que pueda tener su sistema y que solo sea utilizado por otras partes del sistema no debería aparecer en el cuadro del sistema. Una forma útil de pensar en estos servicios de nivel superior es la siguiente: si un caso de uso representa un servicio de nivel superior, entonces debería tener sentido que los actores que interactúan con él soliciten solo ese servicio de su sistema en una sola sesión. (en cualquier sentido, una "sesión" es inteligible en su sistema).
Ejemplo: en el siguiente diagrama, nos gustaría representar los casos de uso de una cámara.
Supongamos que elegimos "Abrir obturador", "Flash" y "Cerrar obturador" como los casos de uso de nivel superior. Ciertamente, todos estos son comportamientos que tiene una cámara, pero ningún fotógrafo tomaría su cámara, abriría el obturador y luego la dejaría, satisfecho con su sesión fotográfica del día. Lo fundamental que hay que tener en cuenta es que estos comportamientos no se realizan de forma aislada, sino que son parte de un caso de uso de más alto nivel, "Tomar una foto". (Tenga en cuenta que tiene sentido que un fotógrafo "tome una foto" solo una vez durante una sesión con su cámara).
Los actores de mi modelo de casos de uso tienen interacciones. ¿Cómo los represento?
Si hay interacciones entre los actores de su sistema, no puede representar esas interacciones en el mismo diagrama que su sistema. Lo que puede hacer en su lugar es dibujar un modelo de caso de uso separado, tratando a uno de los actores en sí mismo como un sistema y su sistema original (junto con los otros actores) como actores en este nuevo diagrama.
Ejemplo: suponga que desea diagramar las interacciones entre un usuario, un navegador web y el servidor con el que contacta. Dado que solo puede tener un sistema en el diagrama, debe elegir uno de los "sistemas" obvios, como el servidor.
Es posible que luego se sienta tentado a trazar líneas de interacción entre los actores, pero esto es un problema porque no está claro qué significa la interacción, por lo que no es útil mostrarlo aquí. Una solución más útil sería dibujar dos diagramas que muestren todas las interacciones, como se muestra a continuación.
¿Los modelos de casos de uso muestran secuencias o procedimientos?
Usando un modelo de caso de uso de UML, no puede.
Los modelos de casos de uso están pensados para ser una descripción horizontal de arriba hacia abajo de la funcionalidad, no una descripción detallada del comportamiento. En su mayor parte, no es una buena idea intentar representar secuencias de acciones con modelos de casos de uso. En su lugar, debería utilizar un diagrama de secuencia o un diagrama de flujo tradicional. (Es posible representar condiciones de ramificación simples con un modelo de caso de uso, como se describe a continuación, pero debe usar esta técnica con moderación porque puede hacer que un diagrama sea ilegible).
¿En qué se diferencia un modelo de caso de uso de UML de un diagrama de flujo tradicional?
Como se mencionó anteriormente, los modelos de casos de uso representan la funcionalidad de arriba hacia abajo, mientras que los diagramas de flujo representan el comportamiento de una manera lineal basada en el tiempo. Además, la forma en que los desarrolla es completamente diferente.
Ejemplo: (Este texto se refiere a los siguientes diagramas).
Al construir un modelo de caso de uso, el paso inicial es identificar todo el comportamiento de nivel superior. Una vez que haya hecho esto (un proceso no muy complicado), ya ha descrito, al menos de una manera de alto nivel, todas las cosas que su sistema sabe hacer.
Luego, puede continuar agregando detalles al descomponer sus casos de uso en más casos de uso que son utilizados por los casos de uso de nivel superior. Sin embargo, en cada etapa del desarrollo, su modelo de caso de uso es una descripción completa de la funcionalidad del sistema: puede carecer de detalles, pero no carecerá de elementos de conjunto de características.
Y si se agrega o elimina funcionalidad o comportamiento durante la vida de su proyecto, el alcance del cambio que necesita hacer es proporcional tanto al alcance del cambio en el sistema como a la madurez de su modelo. Esto es útil porque significa que cuando su modelo es muy joven (solo se dibujan diagramas de alto nivel), realizar cambios radicales en el sistema no implica perder mucho trabajo. Sin embargo, un diagrama de flujo no describe correctamente el sistema hasta que haya terminado de dibujarlo, e incluso entonces, pequeños cambios en el sistema darán como resultado una reelaboración significativa de sus diagramas de flujo. En general, los modelos de casos de uso respaldan el proceso de análisis y diseño mucho mejor que los diagramas de flujo.
¿Cuándo debo usar la flecha de usos en un modelo de caso de uso?
La flecha de usos (o usa un límite como se llamaría en la teoría de grafos tradicional) se extrae de un caso de uso X a otro caso de uso Y para indicar que el proceso de hacer X siempre implica hacer Y al menos una vez (aunque puede implicar hacer muchas veces, "al menos una vez" es la única relación garantizada por este símbolo.) Este símbolo puede denominarse operador de agregación, porque indica que un caso de uso dado es un agregado (formado por partes) cuyos componentes son los casos de uso que utiliza. Si un caso de uso determinado usa varios otros, eso significa que todos los casos de uso de componentes deben completarse en el proceso de completar el caso de uso agregado, aunque no hay una especificación en los Modelos de casos de uso del orden en que se completan. Una breve,
Ejemplo: suponga que desea agregar detalles al diagrama que se muestra a continuación, que representa el sistema de reserva de una aerolínea. Primero, crearía un diagrama separado para los servicios de nivel superior y luego agregaría nuevos casos de uso que conforman los de nivel superior.
Hay un margen de usos de “Facturar pasajero” a “Pesar equipaje” y de “Facturar pasajero” a “Asignar asiento”; esto indica que para poder facturar un pasajero, se debe pesar el equipaje y asignar un asiento. De igual forma, el diagrama indica que para agregar una reserva al sistema se debe verificar el espacio disponible y se debe registrar la información del pasajero. Podrías imaginar desglosar estos casos de uso para mostrar más detalles.
¿Cuándo utilizo la flecha de extensión?
La flecha de extensión (o borde de extensión) se extrae de un caso de uso X a un caso de uso Y para indicar que el proceso X es un comportamiento de caso especial del mismo tipo que el proceso más general Y. Utilizaría esto en situaciones en las que el sistema tiene varios casos de uso (procesos) que tienen algunas subtareas en común, pero cada uno tiene algo diferente que hace que sea imposible agruparlos todos juntos en el mismo caso de uso.
Ejemplo: suponga que desea agregar detalles al diagrama que se muestra a continuación, que representa el sistema de reserva de una aerolínea. Específicamente, lo que le gustaría mostrar es que no todos los asientos a bordo del avión son exactamente iguales (algunos en las ventanas y otros en los pasillos) y, a veces, los pasajeros expresarán una preferencia por uno de estos tipos de asientos pero no por el otro. Pero, por supuesto, no se les puede dar su preferencia de inmediato, porque el asiento que desean podría no estar disponible. Por lo tanto, el proceso de asignación de un asiento junto a la ventana implica verificar la disponibilidad de asientos junto a la ventana, mientras que el proceso de asignación de un asiento en el pasillo implica verificar la disponibilidad de los asientos en el pasillo. Pero a pesar de que estos procesos son diferentes, son bastante similares en varias otras formas, por lo que no tiene sentido ignorar sus similitudes. Por suerte,
¿Cuál es la diferencia entre usos y extensiones?
Para el concepto de generalización, un caso de uso describe una variación de otro caso de uso, use un enlace de generalización. En el siguiente ejemplo, el límite de casos de uso excedido describe una situación en la que no se realiza el escenario habitual de compra en línea. Los casos de uso que generalizan otro caso de uso solo deben especificar un escenario alternativo, incluso excepcional, al caso de uso que se está generalizando. El objetivo general de los casos de uso debe ser el mismo.
Para el concepto de extensión, en algunos casos desea describir una variación en el comportamiento de una forma más controlada. En tales casos, puede definir puntos de extensión en el caso de uso extendido. En el siguiente ejemplo, se dice que la búsqueda por nombre extiende la búsqueda en el punto de extensión del nombre. El enlace de extensión está más controlado que el enlace de generalización, ya que la funcionalidad solo se puede agregar en los puntos de extensión.
Armado de su modelo de caso de uso
Al iniciar un modelo de caso de uso (o modelo de caso de uso), es muy importante mantenerlo simple. A menudo, es más fácil determinar primero los actores del sistema y luego eliminar los casos de uso que realizan. Sus modelos de casos de uso pueden ser tan simples o complejos como desee, sin embargo, los diagramas más simples y menos desordenados son más fáciles de entender y, a menudo, son más poderosos para capturar las tareas del sistema.
