Optimización de Casos de Uso en UML: Relaciones y Errores Comunes

Actividad Opcional: Identificación de Relaciones entre Casos de Uso

En esta actividad, se identifican las relaciones include, extend y generalization entre casos de uso, basándose en sus especificaciones. Esta actividad es opcional, pero recomendable para una mejor comprensión del sistema.

• Relación include: Se determina cuando las especificaciones de dos o más casos de uso contienen secuencias de acciones idénticas. La secuencia repetida se extrae y se crea un nuevo caso de uso que la incluye.
• Relación extend: Se produce cuando existe una secuencia de acciones que ocurren en situaciones excepcionales. Se crea un nuevo caso de uso con esta secuencia, extendiendo la funcionalidad del caso de uso original.
• Relación generalization: Se identifica cuando existen casos de uso con propósitos y secuencias de acciones similares. Se crea un caso de uso genérico, denominado "caso de uso padre".

Errores Comunes en la Especificación de Casos de Uso

Errores Relacionados con el Diseño

La técnica de casos de uso se debe utilizar para la especificación de requisitos del sistema, no para el diseño del mismo. Los errores más frecuentes en esta fase se deben a la inclusión de detalles de diseño:

• Mencionar componentes de la interfaz de usuario: Evitar términos como "botones", "listas desplegables" u "opciones de menú". La especificación debe indicar la información a ingresar o mostrar, pero no el componente específico de la interfaz.
• Incluir detalles de implementación: Frases como "grabar en la tabla clientes en la base de datos" u "ordenar los datos con el algoritmo de la burbuja" son inapropiadas. Estos detalles se determinan en la etapa de diseño.
• Uso de "etc." o "así sucesivamente": La especificación de casos de uso debe ser precisa y completa para permitir una estimación correcta. Evitar estas expresiones ambiguas.

Errores en el Uso de Relaciones

Los errores al incluir relaciones entre casos de uso suelen deberse a la confusión con los diagramas de flujo de datos (DFD) de Yourdon [11]. Esto resulta en diagramas de casos de uso que se asemejan a DFDs. Para evitar este error, se recomienda limitar la profundidad de las relaciones include o extend a no más de dos niveles.

Nota: Algunas bibliografías antiguas pueden referirse a la relación use. Esta relación es obsoleta y corresponde a versiones anteriores de UML.

Vistas en UML: Una Perspectiva General

"Vistas: Proyección de un modelo, visto desde una perspectiva particular, omitiendo entidades irrelevantes para esa perspectiva."

Tipos de Diagramas UML

Área Estructural

Los diagramas estructurales visualizan, especifican, construyen y documentan los aspectos estáticos de un sistema. Una característica estructural es un rasgo estático de un elemento del modelo (ej: un atributo o una operación).

• Vista estática: Diagrama de clases.
• Vistas de diseño: Diagramas de estructura interna, colaboración y componentes internos.
• Vista de casos de uso: Diagrama de caso de uso.

Área Física

• Vista de despliegue: Diagrama de despliegue.